如果您正在阅读本书，您可能知道故事映射是一种处理用户故事的方法，因为它们被用于敏捷流程。现在，正是在这一点上，所有其他与敏捷开发有关的书都在重现“敏捷软件开发宣言”，那是 2001 年由 17 个人写的东西，他们对正在发生的一些适得其反的大过程趋势感到沮丧时间。我很高兴他们写了它。我很高兴许多人都感受到了他们工作的影响。

If you’re reading this book, you likely know that story mapping is a way to work with user stories as they’re used in Agile processes. Now, it’s at this point that every other book that has something to do with Agile development reproduces the “Manifesto for Agile Software Development,” that thing written in 2001 by 17 guys who were frustrated with some of the big counterproductive process trends going on at the time. I’m glad they wrote it. And I’m glad that the impact of their work has been felt by so many.

但很抱歉让你失望了——我不会重印宣言并滔滔不绝地谈论它的重要性。我相信你已经知道为什么会这样。而且，如果您还没有阅读宣言，那么您应该阅读。

But I’m sorry to disappoint you—I’m not going to reprint the manifesto and gush about why it matters. I believe you already know why it does. And, if you haven’t read the manifesto, then you should.

在宣言本应在本章中占据的空间中，我加入了一张有趣的小猫照片。^{[ 4 ]}为什么？因为一次又一次地证明，有趣的小猫照片在互联网上获得的关注远远超过任何宣言所希望的。

In the space that the manifesto would have taken up in this chapter, I am instead including a funny kitten photo.^[4] Why? Because it has been proven time and time again that funny kitten photos on the Internet get far more attention than any manifesto could ever hope to.

那么，您可能想知道，这只小猫与敏捷有什么关系？其实，没什么。但敏捷肯定与这本书有关，与故事和故事映射的演变有关。

So, you might wonder, what does this kitten have to do with Agile? Actually, nothing. But Agile definitely has something to do with this book, and with stories and the evolution of story mapping.

<提示闪回音乐……>

<Cue the flashback music…>

2000 年，我在旧金山的一家初创公司工作，该公司聘请了Kent Beck（创建极限编程并首先描述故事概念的人）作为顾问让软件开发过程继续进行。我倒回去了，但重要的是这个故事的想法是一个古老的想法。如果您刚刚开始使用故事，那么您将失去十年前可能拥有的任何早期采用者身份。Kent 和其他开创了极限编程的人都知道，过去所有这些处理需求的方法都不太奏效。肯特的简单想法是我们应该聚在一起讲述我们的故事；通过交谈，我们可以建立共同的理解，并共同达成更好的解决方案。

I was working at a startup in San Francisco in 2000, and the company had hired Kent Beck (the guy who created Extreme Programming and first described the idea of stories) as a consultant to get the software development process going. I’m rewinding way back, but the important thing is this story idea is an old one. If you’re just starting out with using stories, you lost any early adopter status you could have had a decade or so ago. Kent and others who pioneered Extreme Programming knew that all those ways of doing requirements in the past didn’t work out well. Kent’s simple idea was that we should get together and tell our stories; that by talking we could build shared understanding, and together we’d arrive at better solutions.

当我第一次听到故事这个词时，它让我感到困扰。我会承认的。我们通过将人们想要的重要事物称为故事来贬低它们的想法似乎并不正确。但我学得慢——这是我之前在讨论共享理解时提出的一点。我花了一段时间才真正明白：

When I first heard the term story, it bugged me. I’ll admit it. The idea that we’d trivialize the important things that people wanted by calling them stories didn’t seem right. But I’m a slow learner—a point I brought up earlier when discussing shared understanding. It took me a while to really get that:

甚至在我真正理解为什么故事有这个名字之前，我就意识到我可以在便利贴或卡片上写下一堆故事——一句话或一个简短的标题。我可以四处移动它们并确定它们的优先级，以决定哪个更重要。一旦我确定一个比另一个更重要，我们就可以开始讨论它。这太酷了。为什么我以前从来没有在卡片上写过东西并以这种方式组织它们？

Even before I’d really understood why stories had that name, I realized that I could write down a bunch of stories—a sentence or a short title—on sticky notes or cards. I could move them around and prioritize them to decide which one was more important. Once I decided that one was more important than another, then we could start having a discussion about it. This was super-cool. Why hadn’t I ever written things on cards and organized them this way before?

问题是这张卡片可能只需要软件开发人员几个小时就可以添加到产品中，或者可能需要几天或几周，或者一个月——谁知道呢？我没有——至少在我们开始谈论它之前没有。

The problem was that this one card could be something that might take a software developer just a couple hours to add to a product, or maybe a couple days or a couple weeks, or maybe a month—who knew? I didn’t—at least not until we started talking about it.

当我开始故事对话并了解到我的故事太大时，我在处理我的第一个敏捷项目的故事时陷入了激烈的争论。我希望在下一次迭代中完成这个故事。与我交谈的开发人员告诉我情况并非如此。我觉得我做错了什么。开发人员确定了我们可以讨论的一小部分，可以在我们的下一次迭代中完成。但我很沮丧，因为我们不能谈论大局。我真的很想了解我真正需要的大事需要多少时间。我希望这次讨论能够实现这一点，但它没有。

I got into a nasty argument while working with stories on my very first Agile project when I began a story conversation and learned that my story was too big. I’d hoped to get this story done in the next iteration. The developers I spoke with informed me otherwise. I felt like I’d done something wrong. The developers identified a small part we could talk about that could be accomplished in our next iteration. But I left frustrated that we couldn’t talk about the big picture. I really wanted to understand how much time the big thing I really needed would take. I’d hoped this discussion would accomplish that, and it didn’t.

2001 年，我离开了我所在的团队，开始以不同的方式做事。我和我的团队尝试了一种着眼于大局的故事写作方法。我们努力了解我们正在构建的产品并共同做出权衡。我们使用那一堆带有故事标题的索引卡来组织我们的想法，并将大图分解成我们接下来可以构建的小部分。2004 年，我写了第一篇关于这个想法的文章。然而，直到 2007 年，我才创造出故事地图这个词。

In 2001 I left the team I was on and started doing things differently. I, and my team, tried an approach to writing stories that focused on the big picture. We worked to understand the product we were building and to make tradeoffs together. We used that bunch of index cards with story titles to organize our thoughts and break down that big picture into the small parts we could build next. In 2004, I wrote my first article about this idea. I didn’t coin the term story mapping, however, until 2007.

事实证明，你给某物起的名字很重要。正是在给这种做法起了好名字之后，我才真正看到它传播开来。当时我认为这是一项伟大的发明——也就是说，直到我开始遇到更多的人在做类似的事情，如果不是完全相同的话。我发现了一个规律。

It turns out that the name you give something matters. It was after giving the practice a good name that I really saw it spread. I thought it was a great invention at the time—that is, until I started running into more people who were doing similar if not exactly the same things. I’d discovered a pattern.

我第一次从我的朋友 Linda Rising 那里听到模式的这个定义：当你告诉某人一个好主意，他说，“是的，我们也做类似的事情。” 这不是发明，这是一种模式。

I first heard this definition of a pattern from my friend Linda Rising: when you tell someone about a great idea and he says, “Yeah, we do something like that, too.” It’s not an invention, it’s a pattern.

故事映射是一种模式。这是明智的人为了理解整个产品或整个功能所做的事情。这是他们将大故事分解成小故事的方法。如果您没有自己到达目的地，请不要感到难过。你最终会的。但是阅读这本书会让你避免数周或数月的挫败感。

Story mapping is a pattern. It’s what sensible people do to make sense of a whole product or whole feature. It’s what they do to break down large stories into smaller ones. Don’t feel bad if you didn’t arrive at it on your own. You would have eventually. But reading this book will save you weeks or months of frustration.

如今，一家又一家公司采用了故事地图的理念。我在 SAP 的朋友 Martina 在 2013 年 9 月发送的消息中说：

Today, company after company has adopted the idea of story mapping. My friend Martina at SAP said in a message she sent in September 2013 that:

每周我都会听到来自其他地方的其他人告诉我绘图故事如何帮助他们解决问题。这些天来，我从与他人交谈中学到的东西比我自己学到的要多。

Every week I hear from someone else from somewhere else telling me how mapping stories helped solve a problem for them. These days, I learn more from talking to others than I ever could on my own.

故事的最初想法很简单。它使我们的注意力从共享文档转向共享理解。使用故事的一种常见方法是建立一个故事列表，确定它们的优先级，然后开始谈论它们，然后将它们一次一个地转化为软件。当你听到它时，这听起来很合理。但它会产生一些大问题。

The original idea of stories was a simple one. It turned our focus away from shared documents and toward shared understanding. A common way to use stories is to build a list of them, prioritize them, and begin talking about them and then turning them into software one at a time. That sounds pretty reasonable when you hear about it. But it can create some big problems.

几年前我遇到了加里莱维特。加里是一名正在推出新网络产品的商人。网络产品现在就在那里，它被称为 Mad Mimi，当 Gary 构思他的产品时，它是音乐行业营销界面的缩写。^{[ 5 ]}加里是一位拥有自己乐队的音乐家。他管理自己的乐队，帮助管理其他乐队，同时也是一名录音室音乐家，为客户创作唱片。

A few years ago I met Gary Levitt. Gary was a businessperson in the process of launching a new web product. The web product is out there right now, and it’s called Mad Mimi, which when Gary conceived of his product, was short for music industry marketing interface.^[5] Gary is a musician who had his own band. He managed his band, helped manage others, and was also a studio musician and created recordings for clients.

我遇见加里的那天，他接到了奥普拉·温弗瑞 (Oprah Winfrey) 节目的订单，需要几十个前奏和结尾，以及一些用于广告和类似内容的音乐片段。电视节目的制作人购买它们的方式就像排版时事通讯的人购买剪贴画一样，所以它就像音频剪贴画一样。加里有一个相当大的应用程序的想法，可以帮助像他这样的音乐家和他认识的人在他正在从事的项目中相互合作，以及乐队经理和音乐家需要做的许多其他事情管理和推广他的乐队。

The day I met Gary he had an order from the Oprah Winfrey show for dozens of intros and outros, little bits of music that are used to go out to and come in from commercials and things like that. Producers of television shows buy those the way people laying out a newsletter buy clip art, so it’s like audio clip art. Gary had an idea for a fairly big application that would help musicians like him and people he knew to collaborate with one another on projects like the one he was working on, along with lots of other things a band manager and musician would need to do to manage and promote his band.

Gary 想要构建软件，所以他和某人一起工作，而那个人正在以敏捷的方式工作。那个人告诉加里写下他想要的所有东西的清单，对清单进行优先排序，然后他们会讨论价值最高的东西——最重要的东西——然后开始逐一构建它们。这份清单就是敏捷流程所称的待办事项列表，Gary 创建清单并首先从最重要的事情开始似乎是有意义的。所以这就是他所做的。

Gary wanted to get the software built so he worked with somebody, and that somebody was working in an Agile way. That person told Gary to write down a list of all the things he wanted, prioritize the list, and then they would talk about the highest-valued things—the most important—and start building them one at a time. That list of things is what Agile processes refer to as a backlog, and it seemed to make sense to Gary to create the list and start with the most important things first. So that’s what he did.

加里创建了他的积压工作，开发团队开始一次构建一些东西。与此同时，加里继续为每一个构建的软件支付费用，导致现金流失。该软件正在慢慢成型，但加里可以看出，它需要更长的时间才能符合他的设想，而且他很早就会用完现金。

Gary created his backlog and the development team started building things a bit at a time. In the meantime, Gary was hemorrhaging cash as he continued to pay for each piece of software that was built. The software was slowly taking shape, but Gary could tell it was going to take a lot longer for it to match his vision and he was going to run out of cash long before then.

我认识和加里一起工作的人。我的朋友知道加里压力很大，想帮助他。我认识的人问我是否可以与加里交谈，与他交谈并帮助他组织他的想法。我联系了加里并安排在他位于曼哈顿的办公室与他会面。

I knew the person who was working with Gary. My friend knew Gary was stressing out and wanted to help him. The somebody I knew asked if I could have a conversation with Gary, to talk with him and help him get his ideas organized. I contacted Gary and made arrangements to meet him at his office in Manhattan.

加里和我开始交谈。在他说话的同时，我根据他所说的要点写了卡片。在构建故事地图时，我喜欢一句口头禅。我会说“talk and doc”（动词文档的缩写），这基本上意味着不要让你的话蒸发。将它们写在卡片上，以便您以后可以参考。你会注意到指向卡片上的几个词如何快速帮助每个人回忆起关于它的对话。我们可以在桌子周围滑动它们，在那里我们可以重新组织它们。当我们指向卡片时，我们开始使用这样那样有用的词。它可以节省很多时间。帮助加里具体化他的想法对于获得共同理解至关重要。这对他来说不是一个习惯，所以我很容易在他讲故事的时候写卡片。

Gary and I started talking. And as he talked, I wrote cards with key points from what he said. There’s a mantra that I like when I build story maps. I’ll say “talk and doc” (short for the verb document), which basically means don’t let your words vaporize. Write them down on cards so you can refer back to them later. You’ll notice how pointing to a few words on a card quickly helps everyone recall the conversation about it. We can slide them around the table where we can reorganize them. We start using useful words like this and that as we point to cards. It saves lots of time. Helping Gary externalize his thoughts was critical to getting shared understanding. It wasn’t a habit for him, so it was easy for me to write the cards as he told the story.

我们首先将卡片放在桌面上，但很快就用完了。我拜访他的那天，加里正在搬办公室，他所在的纽约市阁楼里的大部分家具都在地板上。因此，我们将不断增长的卡片地图移到了地板上。

We started by placing cards on a tabletop, but quickly ran out of space. Gary was moving offices the day I visited with him, and much of the furniture in the New York City loft where he was located was off the floor. So we moved our growing map of cards onto the floor.

在一天结束时，地板看起来像这样：

At the end of the day, the floor looked like this:

我不是来这里了解 Gary 的要求的。我们谈论的第一件事不是功能列表。我们不得不后退一点，从头开始。

I wasn’t here to capture Gary’s requirements. And the first thing we talked about wasn’t that list of features. We had to back up a bit and start at the beginning.

我们的第一次谈话集中在构建他的产品理念上。我们谈论了他的生意和他的目标。你为什么要建这个？告诉我对您和使用它的人的好处。它为那些人和你解决了什么问题？当您阅读本文时，您可能会发现我脑子里已经有了那个现在和以后的模型。我试图了解 Gary 正在寻找的结果，而不是他想要构建的输出。

Our first conversation focused on framing his product idea. We talked about his business and what his goals were. Why are you building this? Tell me about the benefits for you and for the people who will use this. What problems does it solve for those people and for you? As you read this you might detect I’ve got that now-and-later model in my head. I’m trying to understand the outcomes Gary is looking for, not the output he wants to build.

如果我放下两张牌，一张放在另一张上面，那么人们就会认为上面的一张更重要。一言不发，如果我只是把一张卡片滑到另一张上面，我已经指出了一些重要的事情。尝试使用目标列表。故意将它们按错误的顺序排列，然后看着与您一起工作的人伸出手来调整它们。我对加里和他的目标做了这个，这帮助他表达了对他来说更重要的东西。

If I put two cards down, one above the other, then people assume that the one above is more important. Without saying a word, if I simply slide a card above another, I’ve indicated something about importance. Try that with a list of goals. Purposely put them in the wrong order and watch the person you’re working with reach out to adjust them. I did this with Gary and his goals, and it helped him express what was more important to him.

加里和我继续交谈和记录。加里和我的下一次谈话是关于购买他的软件的客户和使用他的软件的用户。我们列出了不同类型的用户。我们讨论了他们会得到什么好处，并询问他们为什么要使用该产品以及我们认为他们会用它做什么。这对他们有什么好处？我们建造了一大堆。这些卡片似乎自然而然地落在一堆最重要的用户身上。有趣的是，它是如何在没有明确决定的情况下以这种方式运作的。

Gary and I continued to talk and doc. The next conversation Gary and I had was about the customers who would buy, and users who would use, his piece of software. We listed the different types of users. We talked about what benefits they would get, and asked why they would use the product and what we thought they would do with it. What was in it for them? We built a big pile of those. The cards naturally seemed to fall with most important users higher in the pile. Funny how it works out that way without an explicit decision.

在我们讨论任何细节之前，我已经看出 Gary 的远见卓识。软件开发的一个严峻现实是，要构建的东西总是超出我们的时间和金钱。因此，目标永远不应该是全部构建。目标是尽量减少我们建造的数量。所以我问加里的第一个问题是，“在所有这些不同的用户和他们想做的事情中，如果我们只专注于让其中一个用户兴奋，那会是谁？”

Before we’d gone into any detail at all, I could already see that Gary’s vision was big. One of the tough realities about software development is that there’s always more to build than we have time and money for. So the goal should never be to build it all. The goal is to minimize the amount we build. So the first question I asked Gary was, “Of all these different users and the things they want to do, if we were to focus on thrilling just one of those users, who would it be?”

加里选择了一个，我们开始真正讲故事。

Gary chose one and we started to really tell stories.

Mad Mimi 用户类型

这些是 Gary 为 Mad Mimi 描述的不同类型的用户。只是给他们起名字并写下他们想要的东西就可以帮助我们俩看到这里有很多东西。甚至在讨论功能之前，我们就决定推迟为某些类型的用户创建软件。

These are the different types of users Gary described for Mad Mimi. Just naming them and writing a little about what they want helped us both see that there was a lot here. Even before discussing features, we’d decided to defer creating software for some types of users.

接下来我说，“好吧，让我们想象一下未来。让我们暂时假设这个产品是实时的，让我们谈谈使用它的人生活中的一天并开始讲述这个故事。首先，他们会做这个，然后做这个，依此类推。” 我们从左到右依次讲述这个故事。有时我们回溯并将一些东西放在其他东西的左边，因为它们在卡片上，我们可以很容易地重新排列它们。

I next said, “OK, let’s imagine the future. Let’s assume for a minute this product is live and let’s talk about a day in the life of someone who uses it and start telling the story. First, they would do this, and then this, and so on and so on.” And we told the story in a flow from left to right. Sometimes we backtracked and put things to the left of other things, and because they were on cards, we could easily rearrange them.

使用卡片时自然会发生的另一件有趣的事情是，如果我把一张放在左边，另一张放在右边，我一言不发，我已经指出了顺序。这对我来说有点神奇——但我很容易被娱乐。我惊叹于我们可以不言而喻地交流多少。

The other interesting thing that happens naturally when working with cards is if I put one to the left and another to the right, without saying a word I’ve indicated sequence. This is kind of magical for me—but I’m easily entertained. I marvel at how much we can communicate without saying a word.

当我们交谈和记录时，以及当我写下我们的谈话时，我们正在构建一些非常重要的东西。不，不是地板上那一堆卡片。真正重要的是共同理解。我们正在达成共识。这是 Gary 以前从未与任何人就他的产品创意做过的事情，至少在这种细节级别上没有。他自己从来没有想过这么多。高潮在他的脑海里，有点像你在电影预览中看到的动作场面。

As we talk and doc, and as I write down our conversation, we’re building something really important. No, it’s not that pile of cards on the floor. The something that’s really important is shared understanding. We’re getting on the same page. This is something Gary had never done with anyone before about his product idea, at least not at this level of detail. He’d never even given it this much thought himself. The high points were in his head, sort of like the action scenes you’d see in a movie preview.

在此之前，加里已经完成了他被要求做的事情。他写了一堆故事标题，把它们列在一张清单上，然后一次一个地谈论它们。谈话更多的是关于构建什么的细节，而不是大局。加里的大局中有很多漏洞。你会发现，无论你对你的故事有多清楚，在你绘制地图的时候通过它来谈论它会帮助你发现你自己思维中的漏洞。

Before now, Gary had done what he was asked to do. He’d written a bunch of story titles, put them in a list, and talked about them one at a time. The conversations were more about the details of what to build and less about this big picture. And there were a lot of holes in Gary’s big picture. You’ll find that no matter how clear you are about your story, talking through it while you map will help you discover the holes in your own thinking.

随着我们深入挖掘，我们意识到这个故事也不只是关于一个用户。加里 (Gary) 从一位乐队经理开始，他想宣传他的乐队以及他正在做的工作，以创建宣传并将其通过电子邮件发送给粉丝。然后我们很快不得不谈论乐队的粉丝，并讲述她看到宣传然后计划去看演出的故事。

As we dug deeper, we realized that the story also wasn’t just about one user. Gary’s started with a band manager who wanted to promote his band and the work he was doing to create the promotion and email it to fans. Then we quickly had to talk about the fan of the band, and tell her story about seeing the promotion and then making plans to see a show.

然后，如果我们在某个地方宣传乐队，我们需要讲述场地经理的故事以及他想了解有关宣传的信息。到这个时候，我们的地图已经足够宽了，以至于我们撞到了墙上，所以我们不得不在第一层下面的另一层继续这个故事。这就是为什么照片中的地图有两层。

Then, if we were promoting the band someplace, we’d need to tell the story of the venue’s manager and the information he’d like to learn about the promotion. By this time, our map was wide enough that we bumped into the wall, so we had to continue the story in another layer below the first. That’s why the map in the photograph has two layers.

在讲故事的过程中，有时 Gary 会讲到他很兴奋的部分，然后他会开始描述很多细节。一张卡在另一张上面可以表示优先级。但它也可以表示分解，这只是一个花哨的词，表示较小的细节是更大事物的一部分。正如加里描述的细节，我会把它们记录在一张卡片上，并将它们放在上面大用户步骤的下面。例如，当加里描述制作乐队经理用来宣传演出的传单时，他格外热情，并且有很多细节需要讨论。

During the story, sometimes Gary would get to a part where he was excited and he’d start describing lots of details. One card above another can indicate priority. But it can also mean decomposition, which is just a fancy word for smaller details that are part of a bigger thing. As Gary described the details, I’d record them on a card, and place them below the big user step above. For instance, when Gary described creating the flyer that band managers would use to promote their gigs, he was extra passionate and had lots of details to discuss.

加里住在纽约市，当乐队撰写传单时，他想象着他看到的所有这些非常酷的东西都贴在纽约的墙壁和灯柱上。它们可能看起来像是用胶水和胶带粘在一起然后复印的，但有些真的很优雅和艺术。记录了一些细节后，我说，“我们回过头来再谈细节。让我们继续前进，让这个故事向前发展。” 很容易迷失在细节中，尤其是那些你热衷的细节。但是，当我们试图了解全局时，重要的是在了解所有这些细节之前先了解故事的结尾。至少在这个阶段，我在制图时使用的另一个口头禅是“一英里宽，一英寸深”——或者对于使用公制系统的理智国家的人来说：“一公里宽，一厘米深”。在迷失细节之前先了解故事的结尾。

Gary lived in New York City, and when bands are composing flyers he’s imagining all these really cool things he sees stuck on walls and lampposts in New York. They might look like they were put together with glue and tape and then photocopied, but some were really elegant and artistic. After recording a handful of details, I said, “Let’s come back and get to the details later. Let’s continue on and move this story forward.” It’s easy to get lost in the details, especially the ones you’re passionate about. But, when we’re trying to get the big picture, it’s important to get to the end of the story before catching all those details. Another mantra I use when mapping, at least at this stage, is “think mile wide, inch deep”—or for people in sane countries using the metric system: “kilometer wide, centimeter deep.” Get to the end of the story before getting lost in the details.

最终我们确实走到了加里故事的结尾。乐队经理成功地向成千上万的粉丝宣传了一场演出，演出取得了巨大的成功。到目前为止，我们的产品愿景都很清晰。我说，“现在让我们回去填写细节并考虑一些备选方案。”

Eventually we did get to the end of Gary’s story. The band manager had successfully promoted a gig to thousands of fans who spread the word, and the show was a wild success. The product vision so far was clear in both our heads. I said, “Now let’s go back and fill in the details and consider some of the alternatives.”

在我们确定了故事地图的广度之后，它开始变厚。我们放在地图中每一列顶部的卡片变成了大东西，然后细节分解在它们下面。我们在用户故事的每一步停下来询问：

After we’ve got the breadth of the story map in place, it starts thickening up. The cards we put at the top of each of the columns in the map become big things, and then the details break down below them. We stop at each step in the user’s story and ask:

最后，我们回去填写了很多细节。结果是我们讲述了乐队经理一天的生活故事，以及对乐队经理的成功很重要的其他人：粉丝和场地经理。

At the end of this we’d gone back and filled in a lot of details. The result was that we had told the story about a day in the life of a band manager, as well as the other people important to the band manager’s success: fans and venue managers.

我问加里，“现在呢？我们有所有这些其他用户，还有他们想做的其他事情——你想谈谈他们吗？你可以看到，如果我们继续谈话，我们将需要一个更大的房间。而且，加里，如果你做所有这些事情，那么构建这个产品将需要很多钱。我们可以讨论剩下的事情，但如果我们做了这么多，而你推出了你的产品，然后就这样做了，那看起来它会是一个有价值的产品。”

I asked Gary, “Now what? We have all these other users with other things they want to do—do you want to talk about them? You can see that if we keep talking we’ll need a bigger room. And, Gary, if you do all this stuff, it will take a lot of money to build this product. We could talk about the rest of this stuff, but if we built this much and you launched your product and just did this, that looks like it’d be a valuable product.”

加里同意了，他说：“我要到此为止了。”

Gary agreed, and he said, “I’m going to stop there.”

这个故事的悲伤部分是我问加里，“到目前为止你已经构建了很多软件，但是你构建的软件中有多少是在我们创建的这张地图上的？”

The sad part of this story is that I asked Gary, “You’ve been building a lot of software so far, but how much of the software you’ve built is on this map we’ve created?”

“几乎没有，”加里回答说，“因为当我列出清单并确定优先顺序时，我有点假设我们需要从其他地方开始。我当时在想这件事的整个宏伟愿景，我要花很多年才能达到的愿景，现在我们已经讨论过了，我根本不会从那里开始。”

“Nearly none of it,” Gary replied, “because when I built a list and prioritized things, I sort of assumed we needed to start somewhere else. I was thinking about the whole big vision of this thing, the vision that would have taken me years to reach, and now that we’ve had this discussion I wouldn’t have started there at all.”

故事地图是关于进行良好的老式对话，然后以地图的形式组织它。大多数人看的部分是地图——从左到右的形状，以及人们讲述一个大故事所采取的步骤。从上到下是关于细节的。但是构成产品框架并提供更多上下文的关键部分通常挂在地图上方和周围。它们是产品的目标，以及有关其客户和用户的信息。如果您将地图挂在墙上，您会发现在地图周围添加用户界面 (UI) 草图和其他注释是个好主意。

Story mapping is all about having a good old-fashioned conversation and then organizing it in the form of a map. The part that most people look at is the map—that left-to-right shape with the steps people take to tell a big story. The top to bottom is about the details. But the critical parts that frame the product and give more context are often hung above and around the map. They’re the product’s goals, and information about its customers and users. If you keep a map on the wall, you’ll find it’s good idea to add user interface (UI) sketches and other notes around the map.

在仅仅一天的合作中，加里和我就他想要构建的产品建立了共同的理解。但是我们头顶上形成了乌云，我们知道这一点。我们写的每张卡片中都有很多细节和更多讨论。而且，对于 Gary 来说，所有这些细节和所有这些讨论都等同于他需要花钱来构建软件——他没有的钱。他学到了关于软件开发的一个基本真理：要构建的东西总是比你有时间的多。

In just a day working together, Gary and I built shared understanding around the product he wanted to build. But there was a storm cloud forming above our heads, and we knew it. Inside each of those cards we wrote were lots of details and lots more discussions. And, for Gary, all those details and all those discussions equated to money he would need to spend to build software—money he didn’t have. He’d learned one of the fundamental truths about software development: there’s always more to build than you’ll have time for.

现在，Gary 对使用他的产品的人做出了很多其他重大假设，如果他们真的想要，或者真的可以按照他的设想使用它。但是，眼下，那些事情并不是他最关心的。他需要更加努力地工作，将他的产品创意最小化为首先可行的东西。

Now, there are a lot of other big assumptions Gary was making about the people who’d use his product, and if they really wanted to, or really could use it as he envisioned. But, right now, those things weren’t his biggest concern. He needed to work harder to minimize his product idea to something that was feasible first.

加里的故事最终有了一个圆满的结局。但在下一章中，我将讲述另一个组织的故事，该组织了解到自己要建设的东西太多了，以及它如何使用地图找到可行的解决方案。

Gary’s story eventually has a very happy ending. But in the next chapter I’ll tell the story of another organization that learned it had way too much to build, and how it used a map to find a viable solution.

Artgility——艺术创意与 IT 创意相遇

Ceedee (Clare) Doyle，敏捷项目经理兼教练，Assurity Ltd，新西兰惠灵顿

Ceedee (Clare) Doyle, Agile Project Manager and Coach, Assurity Ltd, Wellington, NZ

背景

Background

The Learning Connexion (TLC) 是一所位于新西兰惠灵顿的艺术学院，教授艺术和创造力。TLC 的课程是独一无二的，因为它们基于“边做边学”；也就是说，实践就是理论。与导师一起，学生制定与他们选择探索的想法相关的简报。

The Learning Connexion (TLC) is an art college in Wellington, New Zealand, that teaches art and creativity. TLC’s programs are unique because they are based on “learning by doing”; that is, the practice is the theory. In conjunction with tutors, students develop briefs that connect with the ideas they choose to explore.

TLC 是一个典型的中小型组织，它开发了临时 IT 系统来支持它当时的需求。学生信息收集在五个不同的地方，每个地方都不一样！TLC 需要某种方式来管理为其工作的学生及其教学方式，这与大多数教育机构截然不同。

TLC was a typical small-to-medium-size organization that had developed ad hoc IT systems to support the needs it had at the time. Student information was collected in five different places and was different in each! TLC needed some way to manage students that would work for it and the way it teaches, which is quite different from most educational establishments.

TLC 没有 IT 项目的经验。为它构建的每个小应用程序都是由某个人的兄弟的朋友的室友的狗使用 Microsoft Excel 和 Access 等简单技术完成的。唯一的商业应用程序（用于法定报告）双重处理来自其他四个来源的数据。

TLC had no experience with IT projects. Each small application that had been built for it had been done by somebody’s-brother’s-friend’s-flatmate’s-dog using simple technologies like Microsoft Excel and Access. The sole commercial application (used for statutory reporting) double-handled data from the other four sources.

作为一名前学生，我一直与团队保持联系，当他们需要帮助时，他们会联系我。2009 年，我在 IT 行业工作了 9 年，自从听说敏捷项目以来，我就想在过去的三年里做一个敏捷项目。这是正确的地点、正确的项目和正确的时间！

As a former student, I had kept in touch with the team and when they needed some help they contacted me. In 2009 I had been in IT for nine years and had wanted to do an Agile project for the last three, ever since I had heard about it. This was the right place, the right project, and the right time to do it!

凤凰计划

Project Phoenix

最初的研讨会将与主要工作人员进行两次为期半天的会议。我和一个庞大的、多元化的团队一起工作，我的目标是建立共同的理解。我首先概述了故事映射的工作原理，并概述了学校学生管理流程中的主要步骤。

The initial workshops were going to be two half-day sessions with key staff members. I was working with a large, diverse group, and my goal was to develop shared understanding. I started with an overview of how story mapping works and an overview of the big steps in the school’s student management process.

在我向他们展示这张图片（故事地图的主干）之前，团队成员每个人都知道他们做了什么，但是，正如发起人爱丽丝所说，这可能是他们第一次清楚地了解自己的工作自己的业务流程以及所有步骤如何交互。

Up until I showed them this picture (the backbone of the story map), the team members each had an idea of what they did, but, as Alice the sponsor said, it was probably the first time they all had a clear picture of their own business process and how all the steps interacted.

从那里我们集思广益人们希望系统做什么。范围很大，故事很多。

From there we brainstormed what people wanted the system to do. The scope was massive, and the stories were many.

美妙之处在于，这些人都是有创造力的人，他们习惯了“欣赏式询问”的方法，所以他们把所有他们能想到的系统需要做的事情都抛诸脑后，就像面包师做面包一样。

The beauty was that these were creative people and they were used to the “appreciative enquiry” method, so braindumping everything they could think of that the system needed to do was something they took to like a baker makes bread.

主要标题（从图中）是查询→入学→注册→课程→完成工作→完成→毕业。

The main headings (from the diagram) were Enquiries → Admissions → Enrollments → Classes → Complete work → Completion → Graduation.

使用故事映射指南，我们然后遍历每个部分以确保它有意义，并让学生了解流程的每个步骤。有几个人突然灵光一闪，因为他们意识到自己在整个过程中的位置以及为什么他们必须做一些活动，而其他人则意识到他们被排除在某些对他们有很大影响的步骤之外。逐步浏览故事地图和我对垂直故事的强调——一起发生——显示了他们可以更好地合作的地方和加倍的步骤。在此之前，团队对其他人在做什么几乎一无所知，但他们突然对整个过程的运作方式有了共同的理解，并形成了共同的词汇。在一个例子中，类由于并非所有学生都上课，因此更名为Delivery 。

Using the story mapping guidelines, we then walked through each section to make sure that it made sense, and got the flow for a student through each step of the process. Several people had lights go on suddenly, as they realized where they fit into the overall process and why they had to do some of their activities, and others realized they were being left out of certain steps that would make a big difference to them. Stepping through the story map and my emphasis on having stories vertically—which happened together—showed places where they could work together better and steps that were doubled up. Until this point, the team had little view of what everyone else was doing, but they suddenly developed shared understanding of how the whole process worked and a common lexicon. In one example, Classes was renamed Delivery because not all students attend classes.

在确定优先级时，它无法确定必须具备的、应该具备的和可能具备的——它不是进就是出。这很简单：在线上方的“没有这个我们就活不下去”，以及在线下方的所有其他内容。在我们完成查询后，团队得到了它，并在一天的剩余时间里完成了剩下的工作。我能够走出它！工作人员接手并开始添加副标题以更好地描述“这些事情必须一起发生，然后再发生这些事情。” 因此，到最后，他们作为一个团队创建了一个学生从最初的调查到毕业所遵循的步骤的大图。

When it came to prioritizing, it wouldn’t have worked to identify the must-haves, should-haves, and could-haves—it was either in or out. It was very simple: “we cannot go live without this” above the line, and everything else below it. After we’d walked through the Enquiries, the team got it and spent the remainder of the day doing the rest. I was able to step out of it! The staff took over and started adding subheadings to better describe that “these things all have to happen together, and then these things.” So, by the end, they had created, as a group, a big picture of the steps a student follows to get from initial enquiry to graduation.

最初的两个半天会议变成了三天的研讨会，人们根据需要来来去去（他们必须教课，等等）。工作场所的灵活性意味着几乎所有员工都经过 Phoenix 会议室，并且物有所值。他们发现这个过程对于了解全局和每个人的需求都非常有用。它还可以确定存在差距的位置，并可以轻松筛选出真正重要的内容。最后，我们清楚地了解了软件的第一版内容。

What started out as two half-day sessions turned into three full days of workshops in which people came and went as the need arose (they had to teach classes, and so forth). The flexibility of the workplace meant that nearly all the staff came through the Phoenix room and had their two cents’ worth. They found the process really useful to get the big picture and for everyone to have their wants included. It also identified where there were gaps and made it easy to sift out what was really vital. At the end of it, we had a clear picture of what was to be in the first cut of the software.

看看这个：

Take a look at this:

这只是来自 Globo.com 三个不同小组的八个团队的领导共同构建的一张相当大的地图的一部分。来自体育、新闻和娱乐的团队一起构建了这个，以思考他们需要做的工作来重建、改造和翻新他们的底层内容管理系统。这是驱动所有这些新闻网站、体育网站、肥皂剧网站、帮助宣传和招募真人秀节目的功能的系统，等等。这个庞大的系统需要能够处理大量的视频源、实时比分和选举结果、照片、突发新闻报道等等。它有很多事情要做，并且需要看起来很好。

That’s just a portion of a pretty big map built by leaders of eight teams from three different groups at Globo.com working together. The teams from Sports, News, and Entertainment built this together to think through the work they needed to do to rebuild, revamp, and renovate their underlying content management system. This is the system that drives all those news websites, sports websites, soap opera websites, features that help publicize and recruit people for reality TV shows, and much, much more. This massive system needs to be able to handle large quantities of video feeds, real-time scores and election results, photographs, fast-breaking news stories, and much more. It has a lot to do, and it needs to look good doing it.

当我在他们制作这张地图的那天到达 Globo.com 办公室时，一起工作的团队即将陷入扁平积压陷阱。各个团队已经准备了各自的优先级积压工作。已经很清楚有大量工作要做，而且每个团队都相互依赖。例如，要推出一个好新闻网站，不仅需要新闻团队，还需要构建基础组件的所有其他团队，让新闻网站使用照片、视频、实时数据和许多其他内容。

When I arrived at the Globo.com offices the day they built this map, the teams working together were about to fall into the flat backlog trap. Individual teams had prepared their respective prioritized backlogs. It was already clear there was a huge amount of work to do, and each team depended on the other. For instance, to get a good news site out would need not just the news team, but also all the other teams that built the foundational components that let the news website use photos, videos, real-time data, and lots of other things.

我和他们坐下来，提醒他们一些他们已经知道的事情：“我知道你们是不同的团队，因为你们专注于不同的领域，但这是对一个内容管理系统的重大修订。你们必须一起释放。在您可以一起看到所有内容之前，您无法计划发布。你必须想象所有这些依赖关系。” 他们同意并迅速开始工作，将他们各自的积压工作重新组织成一张地图。在几个小时内，他们使用便利贴在墙上制作了一张地图，讲述了他们的内容管理系统的故事。

I sat down with them and reminded them of something they already knew: “I understand that you’re different teams because you’re focusing on different areas, but it’s a major revision of one content management system. You’ll have to release together. You can’t plan a release until you can see it all together. You’ve got to visualize all these dependencies.” They agreed and quickly went to work reorganizing their individual backlogs into a map. Within a few hours they built a map on the wall using sticky notes that told the story of their content management system.

当团队成员一起构建地图时，我不在房间里。但是当我当天晚些时候回来时，我对他们建造它的速度感到惊讶。他们对自己很满意，并且完全有权利这样做。他们理解了几个复杂的积压工作，将它们组织成一个连贯的产品故事。现在每个团队都可以看到自己的工作在大局中的位置。

I wasn’t in the room while team members worked together to build the map. But when I returned later in the day, I was amazed at how quickly they’d built it. They were pleased with themselves, and had every right to be. They’d made sense of several complex backlogs, organizing them into one coherent product story. And now each team could see where its work fit into the big picture.

大地图的剖析

Globo 的地图很好地展示了典型地图在您框定、映射和探索大量细节之后的样子。

Globo’s map is good example of what a typical map looks like after you’ve framed, mapped, and explored lots of details.

主干组织地图

The Backbone Organizes the Map

地图的顶部是主干，有时有几个不同的层次。你可以从故事的基本流程开始，这是一个层次。但是，当它变得很长时，再上一层以进一步总结是很有用的。稍后，我将添加一些关于我喜欢在每个级别放置的内容的语言，但我想起了我的一位老朋友，他告诉我不要再尝试使用精确的语言。“这只是大事和小事，”他告诉我。他是对的。

At the top of the map is the backbone, which sometimes has a couple of different levels. You might start with the basic flow of the story, which is one level. But, when it gets really long, it’s useful to go up one more level to summarize things further. Later, I’ll add some language about what I like to put at each level, but I’m reminded of an old friend of mine who told me to stop trying to come up with precise language. “It’s just big things and little things,” he’d tell me. And he’s right.

整个事情有点像你从一种奇怪的苏斯动物身上提取脊椎。你在顶部有这个长长的脊椎骨，有许多不规则间隔的椎骨，还有这些长度不一的长肋骨从它下面垂下来。

The whole thing kind of looks like you extracted the spine out of a weird, Seussian animal. You’ve got this long backbone at the top with lots of irregularly spaced vertebrae, and these long ribs of varying length hanging down from it.

在整个可交付版本中映射

Map in Whole Deliverable Releases

这张地图是由 Globo 的多个团队制作的。有负责视频的开发团队，也有负责在后端构建内容的任务的团队，编辑人员使用这些内容来创建和管理内容。有些团队负责一些底层元数据和数据之间的关联——我永远无法理解的语义标记垃圾。还有一些人负责处理外部展示，以及当用户和/或消费者看到这些东西时它看起来有多好。还有更多的人关注与新闻、体育或娱乐相关的特定功能。

This map was built by multiple teams at Globo. There are development teams responsible for video, and teams charged with the task of building the stuff on the backend that editors use to create and manage content. There are teams responsible for some of the underlying metadata and associations between data—that semantic markup junk that I can never quite grok. And there are people who handle the external presentation and how good this stuff looks when users and/or consumers see it. And still more people are looking after specific features relevant to news, sports, or entertainment.

多个团队必须在这张地图上一起工作，因为对于这个重大修订，没有任何一个团队可以在没有其他团队的情况下发布它的部分。团队构建了一张地图，因为他们需要从整体上考虑发布。

Multiple teams had to work together on this map because, for this major revision, no single team could release its part without the others. The teams built a single map because they needed to think through the release holistically.

在跨多个用户和系统的叙述流中映射

Map in a Narrative Flow Across Many Users and Systems

地图从左边的人开始，他们必须做的事情是为保存新闻故事、图片和视频的屏幕设置基本小部件。然后还有其他类型的人将这些内容组合到肥皂剧或新闻网站的页面上。然后是向页面添加内容的编辑。整个主干讲述了 Globo.com 的许多不同人员如何构建和管理其网站内容的故事。

The map started with people on the left, and the things they had to do to set up basic widgets for the screens that held news stories, pictures, and videos. There were other types of people who then combined those onto pages for soap opera or news websites. Then there were editors who added content to pages. This entire backbone tells the story of how lots of different people at Globo.com construct and manage content in its website.

当您从左到右阅读地图的主干时，它讲述了所有使用该系统的人以及他们为创建和管理站点和内容所做的工作。从左到右的顺序就是我所说的叙事流程，这是一种学术方式来说明我们讲故事的顺序。当然，所有这些人都是同时做所有事情，有时事情并没有按完美的顺序进行，但我们知道这一点。我们只是将它们按顺序排列，以帮助我们讲述故事。

When you read the backbone of the map from left to right, it tells a story about all the people who use the system and what they do in order to create and manage sites and content. The left-to-right order is what I call a narrative flow, which is an academic way of saying the order in which we’d tell the story. Of course, all these people are doing everything all at once, and sometimes things don’t move in a perfect order, but we know that. We just put them in an order that helps us tell the story.

对于这个大系统，叙事流必须贯穿许多不同的用户和系统的故事。我喜欢在主干上方放置便利贴或简单的角色缩略图，这样我就可以在故事的特定时间看到我们在谈论谁。并且可以将后端服务或系统所做的复杂事情拟人化。我在 SAP 的朋友为他们的系统创建了虚构的角色，并使用了星球大战中的 R2D2 或 C3PO 图片。

For this big system, that narrative flow has to cut through many different users’ and systems’ stories. I like to place stickies or simple persona thumbnails above the backbone so I can see who we’re talking about at particular times in the story. And it’s OK to anthropomorphize backend services or complex stuff the system does. My friends at SAP create fictitious personas for their systems and use pictures of R2D2 or C3PO from Star Wars.

当我与构建故事地图的人交谈时，他们会告诉我，“每次我们这样做都会发现漏洞。我们发现了一些我们认为应该由另一个团队负责但它不知道的事情。我们在我们忘记谈论的重要功能之间找到了必要的东西。” 通过一起映射，Globo.com 找到了其中的一些。

When I talk with people who have built story maps, they’ll tell me, “Every time we do this we find holes. We find things that we thought another team should be taking care of, but it didn’t know. We find the necessary stuff in between the big important features that we’d forgot to talk about.” By mapping together, Globo.com found some of that.

在您设想了整个产品或功能之后，开始玩“What-About”游戏就容易多了。这就是我们开始问的地方，“如果出现问题怎么办？” 或者“那些其他用户呢？” 玩 What-About 解决您的任何问题，并在地图主体上添加便利贴以获取您需要的功能创意，以便在您的软件中解决这些问题。在第 1 章中，加里玩 What-About 来考虑选择和备选方案。当您与其他团队一起这样做时，您会发现他们非常善于发现不同系统相互连接时可能出现的问题。

After you’ve envisioned the whole product or feature, it’s easier to start to play the “What-About” game. That’s where we start asking, “What about when this goes wrong?” Or “What about these other users?” Play What-About with any concern you have, and add stickies to the body of the map for feature ideas you’ll need in order to address these things in your software. In Chapter 1, Gary played What-About to consider options and alternatives. When you do this with other teams, you’ll find they’re terrific at spotting problems that might arise where different systems connect to each other.

人们有时对故事地图提出的批评之一是，每次他们坐下来创建故事地图时，他们最终都会得到太多。但我相信，我们现在只是找到了以后会伤害我们的东西，这是一件好事。

One of the criticisms people sometimes make about story mapping is that every time they sit down and create story maps, they end up with way too much. But it’s my belief that we’re just finding the stuff now that would have bitten us later on, and that’s a good thing.

在老式的软件开发方法中，当我们稍后发现新东西时——在我们已经估计交付时间并承诺交付日期之后——我们称这种新东西为范围蔓延。我个人认为范围不会蔓延；理解增长。当人们构建其中一个故事地图时，他们会发现自己的理解存在漏洞。

In the old-school approach to software development, when we’d find that new stuff later on—after we’d already estimated delivery time and committed to a delivery date—we’d call that new stuff scope creep. I personally believe that scope doesn’t creep; understanding grows. And what happens when people build one of these story maps is that they find the holes in their understanding.

当我离开 Globo.com 的内容管理团队时，一切都很棒——相互理解，团队知道该做什么。然而，当我几天后回来与他们核实时，他们再次陷入困境，因为他们意识到有太多的工作要做，可能需要一年多的时间才能完成地图上的所有内容。当然，正如精明的读者所理解的那样，当软件开发人员说要花一年时间才能完成某件事时，他们实际上是指两年。这并不是因为他们不称职，或者他们的日程安排受到挑战，只是估计时间来做我们以前从未做过的事情是我们很不擅长的事情。而且，从本质上讲，我们通常是乐观的动物。

When I left the content management teams at Globo.com, everything was wonderful—understanding was rampant and the teams knew what to do. However, when I came back to check in with them a couple days later, they were struggling again because they realized that there was so much work to be done, that it would likely take more than a year to accomplish everything on the map. And, of course, as savvy readers can appreciate, when software developers say it’s going to take a year to get something done, they really mean two years. It’s not because they’re incompetent, or that they are calendar-challenged, it’s just that estimating the time to do something we’ve never done before is something we suck at. And, by nature, we’re often optimistic animals.

他们对我说：“太多了。我们在这里有很多事情要做，这需要很长时间。”

They said to me, “There’s way too much. We have a lot to do here and it’s going to take a long time.”

“你必须做这一切吗？” 我问。

“Do you have to do it all?” I asked.

他们当然回答说，“是的，因为它都是一个大型内容管理系统的一部分。”

They, of course, replied, “Yes, because it’s all part of one, big content management system.”

“但是这里的项目不会运行那么久，”我回答道。“我认识你们的 CEO，他希望更快地看到结果——对吧？”

“But projects don’t run that long around here,” I replied. “I know your CEO and he’s going to want to see results much faster—right?”

“是的，”他们证实，“他希望在几个月后即将举行的巴西大选中及时看到一些东西！”

“Yes,” they confirmed, “he wants to see something live in time for the upcoming Brazilian election in a few months!”

“你需要所有这些来为选举上线吗？” 我问。

“Do you need all of this to go live for the election?” I asked.

我一问这个问题，就看到灯泡亮了。当然，他们并不需要一切。到目前为止，他们一直专注于确定序列和依赖性，假设他们需要构建所有内容。他们做到了，但这实际上是时间问题。他们改变了想法，将重点放在结果上。

As soon as I asked the question, I could see light bulbs click on. Of course they didn’t need everything. Up ‘til now, they’d been focused on identifying sequence and dependency assuming they’d need to build everything. They did, but it was really a question of when. They shifted their thinking to focus on outcomes.

Globo.com 专注于巴西选举。这些团队特别考虑了在整个选举期间以更新、更性感的互动内容风格成功打动访客、广告商和 Globo 母媒体公司的伟大成果。如果他们那样做，他们就会赢。

Globo.com focused on Brazilian elections. The teams thought specifically about the great outcome of successfully impressing visitors, advertisers, and Globo’s parent media company with newer, sexier styles of interactive content throughout the election. If they did that, they’d have a win.

这不是他们第一次面对不可能的交货日期。他们考虑了一下，意识到他们肯定需要在新闻网站上线，并且可能需要一些其他支持它的东西，因为这是访问者和其他人会去监督巴西选举的地方。专注于新闻网站意味着关注创新的方式来更快地显示实时选举数据和突发新闻。当然，还有一个更新的、最新的视觉设计覆盖了一切。

This wasn’t their first time facing down an impossible delivery date. They thought about it for a bit, and realized that they definitely needed to go live with the news website, and potentially some other things that supported it because that’s where visitors and others would go to monitor Brazilian elections. Focusing on the news website meant paying attention to innovative ways to show real-time election data and breaking news stories faster. And, of course, there was a newer, up-to-date visual design overlaying everything.

团队抓起一卷蓝色画家的胶带，在地图上从左到右拉伸线条以制作水平切片。然后，他们开始上下移动卡片，在蓝线上方和下方移动卡片，以指定哪些事情需要在第一个切片中完成，哪些可以稍后完成。

The teams grabbed a roll of blue painter’s tape and stretched lines across the map left to right to make horizontal slices. They then went to work moving cards up and down, above and below the blue lines to designate which things needed to be done in the first slice, and which could be done later.

思考过程有点像这样：如果我们为巴西大选直播，巴西的很多人都会看到这件事。它会溅起水花降落。它会影响我们的这些网站，我们会看起来很好。这片中的所有内容都是用户在软件发布后需要做的事情，这样他们才能引起轰动。

The thought process worked a bit like this: If we go live for the Brazilian elections, a lot of people in Brazil will see this thing. It’s going to land with a splash. It’s going to affect these websites of ours and we’ll look good. Everything in this slice is what users will need to be able to do after the software is released so they can make that splash.

该地图包含可以改进所有 Globo.com 网络属性的创新内容。但要完成所有这些工作确实需要很长时间。抓住选举创造的市场窗口将是一个不容错过的大好机会。专注于此有助于 Globo 确定第一个版本。

The map contained innovative things that would improve all Globo.com’s web properties. But it really was going to take a long time to get all of it done. Hitting the market window that the elections created would be too big an opportunity to miss. Focusing on that helped Globo identify the first release.

然后，团队开始思考下一个版本应该锚定哪些类型的 Web 属性和市场事件。他们在每个切片的左侧张贴便签，用几个词描述他们对每个发布切片的意图——他们的目标结果。然后他们继续将卡片上下移动到正确的切片中。

The teams then went to work thinking about what kinds of web properties and market events should anchor the next releases. They posted sticky notes to the left of each slice with a few words describing their intention for each release slice—their target outcomes. Then they continued to move cards up and down into their correct slices.

最终，他们有了一个增量发布策略，让他们能够处理随着时间的推移更换整个内容管理系统所需的所有工作，并且以这样一种方式让他们看到每次发布都带来真正的好处。如果他们向下阅读地图的左边缘，他们会得到一个命名版本列表，每个版本都有特定的目标结果。这是一个发布路线图。

In the end, they had an incremental release strategy that let them tackle all the work they needed to do to replace the whole content management system over time, and in such a way that they saw real benefit with each release. If they read down the left edge of the map, they had a list of named releases, each with specific target outcomes. This is a release roadmap.

请注意列表不是一堆功能。这是一份现实世界的好处清单——因为请记住，您的工作不是构建软件，而是改变世界。困难的部分是选择你想为哪些人改变世界，以及如何改变世界。

Notice how the list isn’t a bunch of features. It’s a list of real-world benefits—because, remember, your job isn’t to build software, it’s to change the world. The hard part is choosing which people you want to change the world for, and how.

反之亦然。也就是说，如果您不知道您的目标结果是什么——您想要获得的具体收益——那么几乎不可能确定优先级。

And the opposite is true as well; that is, if you don’t know what your target outcomes are—the specific benefits you’re trying to get—then prioritization is close to impossible.

还要注意 Globo 团队是如何从更换整个内容管理系统的大目标开始的。替换内容管理系统是输出，他们要运送的东西。这样做会带来很多积极的结果。分解真正大块输出的秘诀是专注于更小的、特定的结果。

Notice also how the Globo teams started with a big goal of replacing their entire content management system. Replacing the content management system is the output, the stuff they were going to deliver. Doing that would result in lots of positive outcomes. The secret to breaking down that really big chunk of output was to focus on a smaller, specific outcome.

请记住：结果的背后是从事特定活动的特定人员的特定行为变化。通过关注即将举行的巴西选举，Globo 选择关注关注新闻的人，尤其是那些寻找最新选举细节的人。但是，在将重点放在这些人身上时，它忽略了肥皂剧爱好者、体育爱好者和许多其他类型的用户。那些其他人将不得不对当前站点感到满意一段时间。记住，你不可能总是取悦所有人。

Remember: behind outcomes are specific behavior changes for specific people engaged in specific activities. By focusing on the upcoming Brazilian elections, Globo chose to focus on the people who follow the news, especially those looking for up-to-the-minute election details. But, in placing its focus on those people, it left out soap opera lovers, sports lovers, and lots of other types of users. Those other people would have to be satisfied with the current site for a while longer. Remember, you can’t please everyone all the time.

我可能很容易被打动，但切片是将软件创意组织成故事地图最酷的事情之一。

I may be easily impressed, but slicing is one of the coolest things about organizing software ideas into a story map.

很多时候，我和与我共事的团队都将我们关于完美产品的所有想法都放在了一张地图上，但如果我们创造这一切，我们将面临的工作量不知所措。这一切似乎都很重要。但随后我们退后一步，思考将使用我们产品的特定人群，以及他们需要完成什么才能取得成功。我们将其提炼成一两句话。然后我们切掉所有我们不需要的东西，我们对我们可行的解决方案实际上有多小感到震惊。这很神奇。

Many times I, and the teams I’ve worked with, have placed all our ideas about the perfect product into a map and been overwhelmed by the amount of work we’d have if we created it all. It all seems important. But then we step back and think about the specific people who will use our product, and what they’ll need to accomplish to be successful. We distill that into a sentence or two. Then we carve away everything we don’t need, and we’re shocked at how small our viable solution really is. It’s magic.

第 1 章的Gary继续对他的产品做类似的事情。他最终将注意力集中在乐队经理、歌迷和 Mimi 的内部管理员身上——因为你必须让网站保持运行。加里选择将场地经理和制作音乐家排除在外。最后，他意识到，通过只关注那几个人和推广活动，他最终得到了一个很棒的电子邮件推广平台。所以，对于今天的 Mimi 用户来说，这就是您所知道的体验。

Gary from Chapter 1 went on to do something similar with his product. He eventually narrowed focus to the band manager, the fan, and Mimi’s internal administrator—because you’ve got to keep the site running. Gary chose to leave out venue managers and production musicians. In the end, what he realized is that by focusing on just those few people and the activity of promoting, he ended up with a great email promotion platform. So, for those of you who are Mimi users today, that’s the experience you know.

将我们的思维外化到一张可见的大地图中，可以使所有这些步骤变得更容易。它使许多人协作完成它成为可能。

Externalizing our thinking in a big visible map makes all these steps easier. It makes it possible for lots of people to collaborate to accomplish it.

寻找更小的可行版本

克里斯·辛克尔，SEP

Chris Shinkle, SEP

FORUM Credit Union 是美国最大、技术最先进的信用合作社之一。尽管该公司拥有称职且富有创造力的开发文化，但它还是与 SEP 接洽以构建可与现有商业现成 (COTS) 解决方案相媲美的新网上银行系统。它的目标包括为其移动银行、个人财务管理和文本银行添加功能。

FORUM Credit Union is one of the nation’s largest and most technologically progressive credit unions. Although the company had a competent and creative development culture, it approached SEP to build a new online banking system that rivaled existing commercial off-the-shelf (COTS) solutions. Its goals included adding capabilities for its mobile banking, personal finance management, and text banking.

SEP 通过为期两天的协作故事映射发现会议拉开了合作的序幕，其中包括结果、人物角色和故事映射。该会议有助于促进结构化对话，以确定大量功能想法的优先级。然而，结果和角色不足以确定故事的优先级。两天下来，故事地图覆盖了1000多平方开发区的近两堵墙！

SEP kicked off the engagement with a two-day, collaborative story-mapping discovery session that included outcomes, personas, and story mapping. The session helped facilitate a structured conversation to prioritize a large set of feature ideas. The outcomes and personas were not enough, however, to prioritize the stories. By the end of two days, the story map covered nearly two walls in the 1,000+ square-foot development area!

构建故事地图后，SEP 通过一个简单的优先级模型指导 FORUM 利益相关者：

After the story map was constructed, SEP guided the FORUM stakeholders through a simple prioritization model:

微分器

Differentiator

一项使他们在竞争中脱颖而出的功能

A feature that set them apart from their competition

剧透

Spoiler

一项正在改变其他人差异化因素的功能

A feature that is moving in on someone else’s differentiator

降低成本

Cost reducer

降低组织成本的功能

A feature that reduces the organization costs

桌上赌注

Table stakes

在市场上竞争所必需的功能

A feature necessary to compete in the marketplace

SEP 使用不同颜色的便利贴指示每个故事的类别。有趣的讨论出现了——事实上，一些利益相关者的差异化因素是另一个利益相关者的筹码。很明显，其中许多对话都是第一次发生！具有优先级模型的故事地图使以前从未发生过的对话得以发生。它有助于指导团队围绕优先事项达成共识。

SEP indicated each story’s category using different color sticky notes. Interesting discussions emerged—in fact, some stakeholders’ differentiators were another stakeholder’s table stakes. It was clear many of these conversations were happening for the first time! The story map with the prioritization model enabled conversations to happen that had not happened before. It helped guide the team to come to a shared understanding around priorities.

在给故事贴上标签后，SEP 使用投票系统帮助利益相关者将构思和讨论融合为最有意义的以结果为中心的特征集。令所有人惊讶的是，有几个故事被认为值得推迟或不必要。粗略计算，在编写一行代码之前，可以节省数十万美元。

After labeling the stories, SEP used a voting system to help stakeholders converge the ideation and discussion into the most meaningful set of outcome-focused features. To everyone’s surprise, several stories were deemed postpone-worthy or unnecessary. Rough calculations revealed several hundred thousand dollars in savings before one line of code was written.

当被问及使用故事映射来启动FORUM 首席执行官道格·特鲁 (Doug True) 表示：“当我们第一次启动这个项目时，我们开始使用包括使用人物角色在内的故事映射流程，我对此表示怀疑。具体来说，我关心的是投入到项目的软性方面的时间。第二天它发出咔嗒声，时间的价值实现了。事实上，现在，如果没有这样一个过程，我无法想象追求这种范围和面向成员的影响的项目。”

When asked about using story mapping to kick off the project, Doug True, FORUM’s CEO, said, “When we first kick-started this project with a story mapping process including the use of personas, I was skeptical. Specifically, I was concerned with the time invested to this softer side of the project. On the second day it clicked and the worthiness of the time materialized. In fact, now, I couldn’t imagine pursuing a project of this scope and member-facing impact without such a process.”

有一个术语在软件开发行业中流行了很长时间：最小可行产品，或简称为 MVP。Frank Robinson 因最初创造了MVP一词而受到赞誉，但如今 Eric Ries 和 Steve Blank 的定义占主导地位。尽管有很多聪明人试图定义这个术语，但每个人似乎仍然感到困惑——包括我。我遇到的每个使用该术语的组织都略有不同。即使是同一个组织中的人和同一个对话也常常意味着不同的事情。

There’s a term that’s been kicking around in the software development industry for a long time: minimum viable product, or simply MVP. Frank Robinson is credited with originally coining the term MVP, but these days definitions from Eric Ries and Steve Blank dominate. In spite of multiple smart people trying to define the term, everyone still seems confused—including me. Every organization I run into that uses that term means something slightly different. Even people in the same organization and the same conversation often mean different things.

与字典中的大多数单词一样，它具有多重含义。我将为该术语给出三个定义：一个不好的定义和两个好的定义。

Like most words in the dictionary, it has multiple meanings. I’m going to give you three definitions for the term: a bad one, and two good ones.

这是坏的：

Here’s the bad one:

并且 MVP不是您的用户可以使用的产品，但只有在最简单的情况下，并且只有当他们有很高的痛苦阈值时才可以使用。我经常看到组织通过有人可以使用该产品的论点来合理化他们糟糕的产品决策，而当每个相关人员都清楚他们可能不会选择使用该产品时。

And the MVP isn’t the product that your users could use, but only in the simplest of circumstances, and only if they had a high threshold for pain. I commonly see organizations rationalizing their bad product decisions with the argument that someone could use the product, when it’s clear to everyone involved that they probably wouldn’t choose to.

如果 Globo.com 使用这个定义来分割它的第一个版本，它会产生负面结果。没有人会留下深刻印象。品牌会受到伤害，公司的境况会比什么都不发布还要糟糕。

If Globo.com had used this definition for slicing out its first release, it would have had a negative outcome. No one would have been impressed. The brand would have been hurt, and the company would have been worse off than if it had released nothing at all.

当我们在谈论活的有机体时使用术语viable时，它​​意味着有机体可以在世界上独立生存而不会死亡。当我们谈论软件时，我们指的是同一件事。

When we use the term viable when talking about a living organism, it means that an organism can survive in the world on its own without dying. And when we talk about software, we mean the same thing.

我最喜欢这个定义。最小值是一个主观术语。因此，请具体说明它的主观对象是谁——因为不是你。具体说明您的客户和用户是谁，以及他们需要完成什么。对他们来说最起码的是什么？我向你保证，这会对谈话有很大帮助。这仍然是一场艰难的谈话。但另一种方法是“HiPPO”方法——“最高收入者的意见”。那个更糟糕。

I like this definition best. Minimum is a subjective term. So be specific about who it’s subjective to—because it’s not you. Be specific about who your customers and users are, and what they need to accomplish. What’s minimum to them? I promise you, it’ll help the conversation hugely. It’s still a tough conversation. But the alternative is the “HiPPO” method—the “highest paid person’s opinion.” That one sucks worse.

这些天我更喜欢的术语是minimum viable solution。我与组织合作的大部分事情都不是完整的新产品。它们是新特性或功能，或者是对现有特性的改进。所以术语解决方案似乎更有意义。所以让我修改一下我的定义：

The term I prefer these days is minimum viable solution. Most of the things I work with organizations on aren’t whole, new products. They’re new features or capabilities, or improvements on features already out there. So the term solution seems to make more sense. So let me revise my definition:

困难的部分来了……

Here comes the hard part…

我们只是在猜测。

We’re just guessing.

当我们切出一堆软件功能并将其称为最小可行解决方案时，我们真的不知道它是否是。

When we slice out a bunch of software functionality and call it a minimum viable solution, we don’t really know if it is.

结果的问题在于，在事情出现之前，你无法真正观察到它们。当你切出一个版本时，你不得不假设会发生什么。您可能不得不猜测哪些客户会购买您的产品，哪些用户会选择使用它，如果他们可以使用它，以及在您有的时间内构建什么是可行的。你不得不猜测有多少会让他们开心。这是很多猜测。

The problem with outcomes is that you can’t really observe them until things come out. When you slice out a release, you’re forced to hypothesize what will happen. You might have to guess about what customers will buy your product, what users will choose to use it, if they can use it, and what’s feasible to build in the time you have. You’re forced to guess at how much will make them happy. That’s a lot of guessing.

这很糟糕，因为如果你猜得太低，好吧，那还不到最小值，你就失败了。如果你猜得太高，很多人都会这样做来对冲他们的赌注，那么你就花了太多钱，而且常常冒着根本无法完成事情的风险。最糟糕的是，你可能完全错了，你运送的东西再多也无足轻重。

This sucks, because if you guess too low, well, that’s less than minimal, and you’ve failed. If you guess too high, which many people do to hedge their bets, then you’ve spent too much money and often risk not getting things done at all. And worst of all, you could be just dead wrong, and no amount of what you ship will matter at all.

难怪“你可能发布的最糟糕的产品”的定义仍然盛行。因为那是我们不需要猜测的。

It’s no wonder that the “crappiest product you could possibly release” definition still thrives. Because that’s the one we don’t need to guess about.

我知道你们中的一些人可能在最近几章中感到越来越紧张。您可能会想，Jeff 忽略了最重要的事情！你可能是对的。你最重要的一些事情在故事和故事地图对话中可以讨论的是：

I know that some of you may have been feeling progressively twitchy over the last couple of chapters. You may have thought to yourself, Jeff’s overlooking the most important thing of all! And you might be right. Some of the most important things you can discuss during story and story map conversations are:

这引出了我对 MVP 的第三个定义，正如 Eric Ries 在他的《精益创业》（皇冠企业）一书中所推广的那样。像我们大多数人一样，埃里克通过惨痛的教训了解到，我们只是在猜测。埃里克在一家公司工作，该公司发布了一种它认为可行的产品，但这是错误的。他明智地改变了策略，将重点放在学习上——专注于验证公司在第一个 MVP 版本中所做的所有假设。埃里克提出了一个重要的观点，即我们需要创建更小的实验、原型来检验我们关于什么是最小和可行的假设。如果你采用埃里克的思维方式，你应该这样做，你的第一个产品真的应该是一个实验——然后是一个实验，然后是一个实验，直到你真正证明你得到了正确的产品。

This leads me to my third definition of MVP, as popularized by Eric Ries in his book The Lean Startup (Crown Business). Eric learned the hard way, as most of us do, that we’re just guessing. Eric worked for a company that released a product that it thought was viable, but it was wrong. Intelligently, he changed his strategy to focus on learning—to focus on validating all those assumptions the company had made in its first MVP release. Eric makes the important point that we need to create smaller experiments, prototypes that test our hypothesis about what’s minimal and viable. And if you adopt Eric’s way of thinking, which you should, your first product should really be an experiment—and the one after that, and the one after that, until you really prove that you’ve got the right product.

虽然 Globo.com 的人们能够制定减少建设的计划非常酷，但他们并不是在自欺欺人。他们知道还有很多东西需要学习来证明他们的假设是正确的。他们和其他所有人都需要从这里制定计划以了解更多信息。这就是我们将在下一章中讲述我们的故事的地方。

While it was pretty cool that the folks at Globo.com were able to create a plan to build less, they weren’t fooling themselves. They knew there was lots left to learn to prove their assumptions were good. From here they and everyone else need to create a plan to learn more. And that’s where we’ll pick up our story in the next chapter.

Eric 并没有通过积压用户故事来开始他的工作。他从某人的伟大想法开始，并将其视为公司的机会——因为它确实是。他与公司的领导层进行了交谈，以了解更多信息。他们讨论：

Eric didn’t start his work by building a backlog of user stories. He started with the big idea someone had, and treated it like an opportunity for his company—because it was. He had conversations with leadership in his company to understand more. They discussed:

Eric 需要先与组织中的其他人建立共识，然后才能抓住机会。他知道在接下来的几个月里他需要多次讲述这个产品的故事，所以他最好现在就开始做大事。

Eric needed to build shared understanding with others in his organization before he could take ownership of the opportunity. He knew he was going to need to tell the story of this product many times over the coming months, so he’d better get the big stuff right now.

埃里克相信领导的直觉，但他知道这个伟大的想法只是一个假设。他知道确保想法成功的唯一方法是当他们真正看到它成功时。

Eric trusts his leadership’s intuition, but he knows that this big idea is a hypothesis. He knows the only way to be sure the idea will succeed is when they actually see it succeed.

他首先花时间直接与客户和用户交谈，以真正了解他们。在此过程中，他确认确实有客户遇到了问题，而且他们确实有兴趣购买解决方案。埃里克与可能使用该产品的人交谈。他们没有今天的产品，而且只有很差的解决方法来解决新产品创意可以解决的问题。

He first spent time talking to customers and users directly to really learn about them. Along the way he validated that there really were customers who had the problem, and they really were interested in buying a solution. Eric talked to the people who’d likely use the product. They didn’t have the product today, and had only poor workarounds to address the problems the new product idea would solve.

在 Eric 与客户和用户交谈的同时，他一直在建立一个他认为适合试用他的新软件的人选。一些公司将这些人称为客户开发伙伴。跟踪这个细节，因为它会在故事的后面出现。

While Eric’s been talking with customers and users, he’s been building up a pool of people he thinks are good candidates to try his new software. Some companies refer to these people as customer development partners. Keep track of this detail, because it’s going to come up later in the story.

实际上，在这个阶段，不仅仅是埃里克。Eric 与一小群其他人一起工作，他们花了很多时间与客户交谈，在这样做的过程中，他发现解决问题并不那么容易——而且还有其他问题需要首先解决。你要带走的重要一点是，他们学得越多，原来的机会就改变得越多——最终改变了很多。幸运的是，他们并没有按照要求去做。那不会为他们的客户或他们的组织服务。

Actually, during this stage, it wasn’t just Eric. Eric was working with a small team of others who spent lots of time talking to their customers, and, in doing so, found that solving the problem wasn’t so easy—and that there were other problems that needed to be solved first. The important thing for you to take away is that the more they learned, the more the original opportunity was changed—eventually, a lot. It’s lucky they didn’t just get to work building what they were told to. That wouldn’t have served their customers or their organization.

到目前为止，埃里克和他的团队在与客户交谈后，对他们可以构建用户可以使用的解决方案类型有了具体的想法，并通过这样做获得他们的雇主想要的好处。现在，埃里克和他的团队可以在这里“全力以赴”——他们可以赌上一切。他们本可以积压一些故事来描述他们的解决方案，然后组建一个团队来构建它。因为他们是聪明人，所以他们会使用故事地图从大创意转移到要构建的具体部分。但是，因为他们真的很聪明，所以他们此时要做的最后一件事就是构建软件。

By now Eric and his team, after talking to customers, had specific ideas for the type of solution they could build that users could use, and by doing so get the benefit their employers wanted. Now, here’s where Eric and his team could have gone “all in”—where they could have bet it all. They could have built a backlog of stories that described their solution and set a team to work building it. Because they’re smart people, they’d have used a story map to move from the big idea to the specific parts to build. But, because they’re really smart, the last thing they’re going to do at this point is to build software.

正是在这里，埃里克开始担任该产品的所有者。他首先将他的解决方案设想为一堆简单的叙事故事——用户场景。然后他开始将这个想法设想为一个简单的线框草图。然后他创建了一个更高保真度的原型。这不是工作软件。这是一个简单的电子原型，使用 Axure 或 PowerPoint 等简单工具创建。

It’s around here that Eric began to act as the owner for this product. He moved to envision his solution first as a bunch of simple narrative stories—user scenarios. Then he moved to envisioning the idea as a simple wireframe sketch. And then he created a higher-fidelity prototype. This wasn’t working software. It was a simple electronic prototype, created with a simple tool like Axure, or maybe even PowerPoint.

所有这些都是 Eric 的学习步骤。他们帮助他设想他的解决方案。最终，他想将他的解决方案展示在用户面前，看看他们的想法。但他知道，在将其摆在他们面前之前，他首先需要确信它能解决他们的问题。

All of these are learning steps for Eric. They help him envision his solution. Ultimately, he wants to put his solution in front of his users to see what they think. But he knows he first needs to feel confident it solves their problems before he puts it in front of them.

现在，我对你隐藏了一个重要的细节。Eric 实际上是一名交互设计师。他是那种习惯于与客户和用户共度时光，并习惯于构建这些简单原型的设计师。但是，对于这个新产品，他也是产品负责人——对产品的成功负最终责任的人。Eric 公司的其他产品负责人没有他的设计技能，他们非常明智地与设计师结对，以帮助采访用户和构想解决方案。

Now, I’ve hidden an important detail from you. Eric was actually an interaction designer. He’s the kind of designer who’s used to spending time with customers and users, and used to building these simple prototypes. But, for this new product, he’s also the product owner—the one ultimately responsible for the product’s success. There are other product owners in Eric’s company who don’t have his design skills, and they very sensibly pair with designers to help with both interviewing users and envisioning solutions.

Eric 最终确实将原型带回给了用户。我当时不在场，所以我不知道 Eric 到底发生了什么。但我遇到过很多次这种情况，而且我总是对我从真正使用我的解决方案的人那里学到的东西感到惊讶。我只能告诉你的是，为惊喜和坏消息做好准备。事实上，庆祝这个坏消息，因为你可能会在几个月后，在你构建软件之后收到同样的坏消息。那才是真正糟糕的时候。现在，进行更改的成本很低，您应该这样做。埃里克做到了。

Eric did eventually bring prototypes back to users. And I wasn’t there, so I don’t know what really happened for Eric. But I’ve been in these situation lots of times, and I’m always surprised about what I learn from the people who’ll really use my solution. All I can tell you is, be prepared for surprises and bad news. In fact, celebrate the bad news, because you could have received the same bad news months later, after you’d built the software. That’s when it really sucks. Right now, it’s cheap to make changes, and you should. And Eric did.

在多次迭代他的解决方案并将其展示给客户后，Eric 确信他有一个非常好的解决方案创意。当然，现在他可以建立积压工作，并让他的开发团队着手将原型解决方案转变为真正可用的软件。但埃里克不会那样做。好吧，不完全是这样。这是一个比他愿意接受的更大的赌注。

After iterating his solution many times and showing it to his customers, Eric was confident he had a pretty good solution idea. Surely now he could get that backlog built, and get his team of developers to work turning that prototyped solution into real working software. But Eric’s not going to do that. Well, not exactly that. That’s a bigger bet than he’s willing to take.

Eric 对他认为可行的解决方案进行了原型设计。但他不确定它是否是最小的——因为他向人们展示了很多很酷的想法。如果你向人们展示所有很酷的想法，他们当然会喜欢它们。但埃里克知道他的工作是尽量减少他建造的数量并仍然让人们开心。他能拿走多少，仍然有可行的解决方案？

Eric has prototyped what he believes is a viable solution. But he’s not really sure if it’s minimal—because he showed people lots of cool ideas. And if you show people all the cool ideas, of course they’ll love them. But Eric knows his job is to minimize the amount he builds and still keep people happy. How much could he take away and still have a viable solution?

埃里克还知道一些有点令人不安的事情。他知道那些说他们喜欢它并使用它的人也只是在猜测。

Eric also knows something else that’s a bit disturbing. He knows the people who said they’d like it and use it are just guessing, too.

回想一下你自己买东西的时候。您可能看过产品。您可能已经看到销售人员演示了很酷的功能。您可能已经亲自试用了这些很酷的功能，并且您可以想象真正使用并喜欢该产品。但是当你购买产品并真正开始使用它时，你会发现这些很酷的功能并没有那么重要。真正重要的是您没有想到的功能。而且，最糟糕的是，也许你根本不需要那么多产品。好吧，也许这只是我在说的。但是我的车库里有很多东西我希望我从来没有买过。

Think back to when you’ve bought something yourself. You may have looked at the product. You might have watched a salesperson demonstrate the cool features. You may have tried out the cool features for yourself, and you could imagine really using and loving the product. But when you bought the product and actually started using it, you found the cool features didn’t matter so much. What really mattered were features you hadn’t thought about. And, worst of all, maybe you didn’t really need the product that much after all. OK, maybe it’s just me I’m talking about. But I’ve got lots of stuff in my garage that I wish I’d never bought.

回到埃里克。他知道他的客户和用户可以想象该产品会很好用，并且知道这一点让他有信心加大赌注。但真正的证据是那些人每天都选择使用它。这就是他正在寻找的真正结果——也是能让他的公司获得真正想要的利益的唯一结果。要了解这一点，需要的不仅仅是原型。

Back to Eric. He knows his customers and users can imagine the product would be great to use, and knowing that gives him the conviction to up his bet. But the real proof is when those people actually choose to use it every day. That’s the real outcome he’s looking for—and the only outcome that’ll get his company the benefit it really wants. And it’s going to take more than a prototype to learn that.

现在，埃里克在这里展示了他的聪明才智。

Now, here’s where Eric gets to show how smart he really is.

Eric 和他的团队确实开始着手构建软件。但他们的首要目标不是构建最小可行产品。实际上，它是为了构建一些不那么简单的东西——刚好足以让潜在用户可以用它做一些有用的事情。这是一款不会给太多人留下深刻印象的产品，他们甚至可能会讨厌它。这绝对不是您希望营销和销售人员推销的产品。事实上，您唯一希望看到该产品的人是有一天可能会使用该产品并且真诚地关心找到能够解决他们问题的产品的人。

Eric and his team actually do get to work building software. But their first goal isn’t to build a minimum viable product. Actually, it’s to build something less than minimal—just enough that potential users could do something useful with it. This is a product that wouldn’t impress too many people, and they might even hate it. It’s definitely not a product you’d want your marketing and sales people out there pitching. In fact, the only people you’d want to see this product are people who may one day use the product, and honestly care about finding a product that solves their problem.

恰好，埃里克身边就有一小群这样的人。这是他在了解和验证问题时与之合作的客户和用户。他们是他的发展伙伴。他们是对早期原型提供反馈的人。埃里克认为其中有一部分最能帮助他学习。他们是他会把这个低于最低限度——而且绝对不可行的——产品放在第一位的人。他希望他们能成为他的早期采用者。

It just so happens that Eric has a small group of people just like that. It’s the customers and users he worked with earlier when he was learning about and validating the problem. They’re his development partners. They’re the ones who gave feedback on early prototypes. And there’s a subset of them that Eric believes can best help him learn. They’re the ones he’ll put this first, less-than-minimum—and definitely not viable—product in front of. He hopes they’ll become his early adopters.

他就是这么做的。

And that’s what he did.

这是 Eric 指出他当前积压的一部分。拍摄这张照片时，他已经向他的开发合作伙伴发布了软件。在他这样做之后，他特意与他们交谈以获取他们的反馈。他的团队还建立了一些简单的指标，这样他们就可以衡量人们是否真的在使用该软件，以及他们具体在软件中做了什么。

This is Eric pointing out a slice of his current backlog. When this picture was taken, he’d already released software to his development partners. After he did, he made a point of talking to them to get their feedback. His team also built in some simple metrics so they could measure whether people were really using the software, and what they did in the software specifically.

埃里克知道人们很有礼貌。他们可能会说他们喜欢某个产品，但从不使用它。“使用它”是他想要的真正结果，礼貌对他没有帮助。Eric 也知道有些人要求很高。他们可能会列出产品存在的所有问题，或者抱怨错误，但指标可能会告诉我们他们每天都在使用它。这是一件好事，尽管他们一直在抱怨。抱怨也很好，因为它让埃里克知道他下一步应该改进的地方。

Eric knows that people are polite. They may say they like a product, but then never use it. The “using it” is the real outcome he wants, and polite isn’t helping him. Eric also knows some people are demanding. They may list all the problems the product has, or complain about bugs, but the metrics may be telling us that they use it every day anyway. And that’s a good thing, in spite of all their complaining. The complaining is good, too, because it gives Eric ideas about where his next improvements should be.

Eric 的积压工作被组织成一个故事地图，顶部用黄色便签纸表示主干。那些黄色的便利贴上有简短的动词短语，讲述了他的用户将在产品中做什么的大故事，但是是在高层次上。下面是所有细节——他们将做的具体事情以及真正使用该产品所需的事情。虽然他和他的团队处理的细节随着版本的不同而变化，但主干仍然非常一致。

Eric’s backlog is organized as a story map with the backbone in yellow stickies across the top. Those yellow stickies have short verb phrases on them that tell the big story of what his users will do in the product, but at a high level. Below it are all the details—the specific things they’ll do and need to really use the product. While the details he and his team work on change from release to release, the backbone stays pretty consistent.

磁带上方的顶部切片是埃里克和他的团队目前正在制作的切片。此版本需要 Eric 进行两次冲刺。他正在使用 Scrum 开发流程，其中他的冲刺是两周的时间盒。所以两次冲刺基本上相当于一个月。在其下方是沿着电路板运行的切片。下一个切片包含他们认为下一个版本可能是什么，等等。在每个切片的左边，就像 Globo.com 团队一样，挂了一张便签，上面有发布名称和一些关于他们想在此版本中学习的内容。除了最高版本，上面张贴了呆伯特卡通片。这是他们团队的一个内部笑话，我没有参与其中。

The top slice, above the tapeline, is the one Eric and his team are working on right now. This release will take Eric two sprints. He’s using a Scrum development process where his sprints are two-week time-boxes. So two sprints equate to basically a month. Below that are slices running down the board. The next slice contains what they think the next release might be, and so on. To the left of each slice, just as with the Globo.com team, hangs a sticky note with the release name and a few words about what they want to learn in this release. Except for the top release, which has a Dilbert cartoon posted over it. It’s an inside joke in their team that I wasn’t in on.

如果仔细观察，当前切片的顶部有点被清理掉了。我在它们原来所在的地方画了一些便利贴。但它们已经不存在了，因为那些在上面的东西是他的团队将首先建造的东西。当团队成员一起工作来计划他们的工作时，他们移除了那些便利贴并将它们放在任务板上，位于故事地图待办事项列表的右侧。该任务板显示了他们现在在这个冲刺中正在处理的故事，以及交付任务——开发人员和测试人员需要做的具体事情，以将故事中的想法转化为可用的软件。

If you look closely, the top of that current slice is sort of cleaned out. I’ve drawn in some sticky notes where they used to be. But they’re not there anymore because those things that were on the top are the first things his team will build. As the team members worked together to plan their work, they removed those sticky notes and placed them on a task board to the right of the story-mapped backlog. That task board shows the stories they’re working on now in this sprint, along with delivery task—the specific things that the developers and testers will need to do to turn the ideas in the story into working software.

埃里克的故事地图积压工作中有一个更妙的地方，也是证明他聪明的一个地方，就是最上面那部分的厚度。它的厚度是它下面的切片的两倍。当 Eric 和他的团队完成切片并交付时将它交给他们的开发合作伙伴——他们称之为测试版客户——他们会将便利贴从下面的切片中移上去。当他们这样做时，他们将对下一个分割版本进行更详细的讨论。他们会玩 What About 来发现问题并填写详细信息。他们将在下一个版本中讨论一些想法，这次讨论可能会导致他们将大想法分成两个或三个较小的想法。然后，他们将需要该切片中的垂直高度来确定优先级 - 以选择首先构建的内容。

One finer point of Eric’s story-mapped backlog, and one that proves he’s smart, is the thickness of that topmost slice. It’s twice as thick as the slices below it. When Eric and his team finish a slice and deliver it to their development partners—what they call their beta customers—they’ll move the sticky notes up from the slice below. When they do, they’ll have lots more detailed discussion about this next sliced-out release. They’ll play What About to find problems and fill in details. They’ll talk about some of the ideas in the next release, and this discussion may result in their splitting the big idea into two or three smaller ideas. And then, they’ll need the vertical height in that slice to prioritize—to make choices about what to build first.

看看他们有多聪明？

See how smart they are?

埃里克可能已经开始了整个过程，关于最小可行产品可能是什么的想法，但他故意构建了一些不最小的开始。然后他每个月都会增加一点。他从他的开发合作伙伴那里得到反馈——既有与他们交谈的主观内容，也有他从查看数据中获得的更客观的内容。

Eric may have started this whole process with an idea about what the minimum viable product might be, but he’s purposely built something less than minimal to start with. He’s then adding a bit more every month. He’s getting feedback from his development partners—both the subjective stuff from talking to them, and the more objective stuff he gets from looking at data.

他将保持这一策略，慢慢地发展和改进产品，直到他的开发合作伙伴真正开始定期使用该产品。事实上，埃里克希望他们成为向其他人推荐产品的人——真正的参考客户。当他们这样做时，他就知道自己找到了最低限度和可行的方法。那时产品可以安全地投放市场并疯狂销售。如果埃里克和他的团队以前曾尝试出售它，他们最终会遇到很多失望的客户——与他在整个过程中建立私人关系的那些人相比，他们要友好得多。

He’ll keep up this strategy, slowly growing and improving the product, until his development partners actually start using the product routinely. In fact, what Eric’s hoping for is that they become people who’d recommend the product to other people—real reference customers. When they do, that’s when he knows he’s found minimum and viable. And that’s when the product is safe to market and sell like crazy. If Eric and his team had tried to sell it before, they’d have ended up with lots of disappointed customers—people a lot less friendly than those with whom he built personal relationships throughout this process.

埃里克本可以做的是把他最后的、最好的原型，分解成所有的组成部分，然后开始一部分一部分地构建它。许多个月后，他会有一些东西要释放。如果他的大猜测是正确的，他就会知道。在这一点上你需要相信我，但它不会是——因为它很少是。

What Eric could have done is to take his last, best prototype, break it down into all its constituent parts, and start building it part by part. Many months later, he’d have had something to release. And he’d have learned then if his big guess was right. You’ll need to trust me on this, but it wouldn’t have been—because it rarely is.

这是我的朋友 Henrik Kniberg 制作的简单可视化。它很好地说明了一个失败的发布策略，在每次发布时我都会得到一些我不能使用的东西，直到最后一次发布时我得到了我可以使用的东西。

This is a simple visualization made by my friend Henrik Kniberg. It beautifully illustrates a broken release strategy where at every release I get something I can’t use, until the last release when I get something I can.

Henrik 建议采用这种替代策略：

Henrik suggests this alternative strategy:

如果我以这种方式计划我的发布，那么在每次发布中我都会提供一些人们可以实际使用的东西。现在，在这个愚蠢的交通示例中，如果我的目标是长途旅行并随身携带一些东西，而你给了我滑板，我可能会感到有点沮丧。我会让你知道带着那东西长途旅行是多么困难——尽管在车道上闲逛很有趣。如果你的目标是让我高兴，你可能会为此感到难过。但你真正的目标是学习，你做到了。所以这很好。你了解到我想去更远的地方旅行，如果你接受了它，你也会了解到我很重视玩得开心。

If I plan my releases this way, in each release I deliver something people can actually use. Now, in this silly transportation example, if my goal is to travel a long distance and carry some stuff with me, and you gave me a skateboard, I might feel a bit frustrated. I’d let you know how difficult it was to travel long distances with that thing—although it was fun to goof around with it in the driveway. If your goal was to leave me delighted, you might feel bad about that. But your real goal was to learn, which you did. So that’s good. You learned I wanted to travel farther, and if you picked up on it, you also learned I valued having fun.

在 Henrik 的进度中，自行车发布前后情况开始好转，因为我实际上可以将其用作足够的交通工具。而且，在摩托车级别，我真的可以看到这对我有用——而且我也很开心。这对我来说可能是最低限度和可行的。如果我真的喜欢摩托车，也许我的下一个最佳选择是更大、更快的哈雷戴维森，而不是跑车。我现在正走向中年危机，哈雷听起来不错。但在我试过摩托车之后，我们都从中学到了一些东西，我们才能做出最好的决定。

In Henrik’s progression, things start picking up at around the bicycle release because I can actually use it as adequate transportation. And, at about motorcycle level, I can really see this working for me—and I’m having fun too. That could be minimum and viable for me. If I really love the motorcycle thing, maybe my next best step would be a bigger, faster Harley-Davidson, and not a sports car. I’m headed for a midlife crisis right now and that Harley is sounding pretty good. But it’s after I try the motorcycle, and we both learn something from that, that we can best make that decision.

但是那些需要长途旅行和有孩子的人呢？对于该目标市场，这些都不是好的选择。

But what about other folks who need to travel longer distance, and who have kids? For that target market, none of these would be good choices.

始终牢记您的目标客户、用户和您希望的结果。从所有类型的用户那里获得同样好的结果真的很难。所以专注。

Always keep your target customers, users, and the outcomes you’re hoping for in mind. It’s really tough to get the same great outcome from all types of users. So focus.

我的朋友埃里克所做的是应用经过验证的学习策略——精益创业思想中的一个重要概念。埃里克知道他正在解决的问题，他正在解决的客户和用户，以及他想到的解决方案都是假设。其中很多都是非常好的假设。但它们都是相同的假设。Eric 着手了解这些假设，然后验证它们，从客户和用户面临的问题转向他为他们提供的解决方案。在每一步中，他都以学习某些东西为明确目标来做或构建一些东西。

What my friend Eric did is apply a validated learning strategy—one of the important concepts in Lean Startup thinking. Eric knew that the problems he was solving, the customers and users he was solving them for, and the solutions he had in mind were all assumptions. Lots of them were pretty good assumptions. But they were assumptions just the same. Eric set out to understand the assumptions and then validate them, moving from the problems customers and users faced to the solutions he had for them. At each step he did or built something with the explicit goal of learning something.

Eric 所做的是 Eric Ries 描述的构建-测量-学习循环的核心。根据 Ries 的定义，Eric 发布的每个版本都是最小可行产品。但您可以看到，在他的目标客户和用户眼中，它是不可行的——至少目前还不行。出于这个原因，我喜欢将 Ries 的 MVP 称为最小可行产品实验——或简称 MVPe。这是我可以构建的最小的东西来学习一些东西。我所学到的是推动了解在我的目标客户和用户眼中什么是真正可行的。

What Eric did is the heart of the build-measure-learn loop described by Eric Ries. And by Ries’s definition, each release that Eric shipped was a minimum viable product. But you can see that it wasn’t viable in the eyes of his target customers and users—at least, not yet. For that reason, I like referring to Ries’s MVP as a minimum viable product experiment—or MVPe for short. It’s the smallest thing I could build to learn something. And what I learn is driving toward understanding what’s really viable in the eyes of my target customers and users.

Eric 在此过程中使用了很多工具和技术。但用文字和图片讲故事一直是他工作方式的一部分。使用地图来组织他的故事帮助他在反复改进他的产品以使其可行的过程中牢记他的客户、用户和他们的旅程。

Eric used lots of tools and techniques along the way. But telling stories using words and pictures was always part of the way he worked. Using a map to organize his stories helped him keep his customers, users, and their journey in mind as he iteratively improved his product to viable.

我喜欢用产品发现这个词来描述我们在这个阶段真正做的事情。我们的目标不是建造东西；相反，它是为了了解我们是否在构建正确的东西。碰巧，构建一些东西放在客户面前是了解我们是否正在构建正确的东西的最佳方式之一。我借用了Marty Cagan对发现的定义。^{[ 6 ]}我对发现的定义包括精益创业实践、精益用户体验实践、设计思维实践和大量其他想法。我在发现期间所做的事情不断发展。但目标保持不变：尽快了解我是否正在构建正确的东西。

I like using the term product discovery to describe what we’re really doing at this stage. Our goal isn’t to get something built; rather, it is to learn if we’re building the right thing. It just so happens that building something to put in front of customers is one of the best ways to learn if we’re building the right thing. I borrow my definition of discovery from Marty Cagan.^[6] And my definition of discovery includes Lean Startup practice, Lean User Experience practice, Design Thinking practice, and loads of other ideas. And what I do during discovery continues to evolve. But the goal stays the same: to learn as fast as possible whether I’m building the right thing.

如果我们认识到我们的目标是学习，那么我们就可以最大限度地减少我们构建的内容，而只专注于构建我们需要学习的内容。如果你做得很好，这意味着你早期构建的东西可能还没有准备好生产。事实上，如果是这样，你可能做得太多了。

If we recognize that our goal is to learn, then we can minimize what we build and focus on building only what we need to learn. If you’re doing this well, it means that what you build early may not be production ready. In fact, if it is, you’ve likely done too much.

举个例子：当我是一家为大型连锁零售商构建软件的公司的产品负责人时，我知道我的产品需要在后端的大型 Oracle 数据库上运行。但是数据库人员有时让我很难共事。他们想仔细检查我所做的每一个改变。有时简单的更改需要一周或更长时间。这让我的团队和我的速度放慢了太多。数据库人员的担忧是有道理的，因为所有其他应用程序都依赖于该数据库。打破它对每个人来说都是有风险的。但是他们有一个运行良好的流程来评估和更改数据库——只是花了很长时间。

Here’s an example: when I was a product owner for a company that built software for large, chain retailers, I knew my products needed to run on a big Oracle database on the backend. But the database guys were sometimes a pain for me to work with. They wanted to scrutinize every change I made. Sometimes simple changes would take a week or more. That slowed down my team and me too much. The database guys’ concerns made sense, since all the other applications depended on that database. Breaking it was really risky for everyone. But they had a well-oiled process for evaluating and making database changes—it just took a long time.

对我来说，风险最大的部分是确保我的产品是正确的。因此，我们使用简单的内存数据库构建了软件的早期版本。当然，它们无法扩展，而且我们永远无法向大量普通用户发布我们的早期版本。但是我们早期的最小可行产品实验（当时我们没有这么称呼它们）允许我们用一小部分客户测试想法并且仍然使用真实数据。在与客户进行多次迭代并找到我们认为可行的解决方案之后，我们将更改数据库并将我们的应用程序关闭内存数据库。数据库人员也喜欢我们，因为他们知道当我们做出改变时，我们相信他们是正确的。

The riskiest part for me was making sure my product was right. So we built early versions of software using simple, in-memory databases. Of course, they wouldn’t scale, and we could never release our early versions to a large general audience. But our early minimum viable product experiments (we didn’t call them that then) allowed us to test ideas with a small subset of customers and still use real data. After several iterations with customers, and after we found a solution we believed would work, we’d then make the database changes and switch our application off the in-memory database. The database guys liked us too, because they knew that when we made changes, we were confident they were the right ones.

加里使用地图摆脱了扁平积压陷阱，看到了他的产品的大局，然后真正开始关注它是为谁服务的以及它应该是什么。

Gary used a map to get out of the flat-backlog trap and see the big picture of his product, and then to really start focusing on who it was for and what it should be.

Globo.com 的团队使用地图来协调跨多个团队的大计划，并切出他们认为可行的解决方案的一部分工作。

The teams at Globo.com used a map to coordinate a big plan across multiple teams and slice out a subset of work they believed would be a viable solution.

Eric 使用地图将不太可行的版本分割成最小可行产品实验，这使他能够迭代地找到可行的东西。

Eric used a map to slice out less-than-viable releases into minimum viable product experiments that allowed him to iteratively find what would be viable.

最后一个挑战似乎困扰着软件开发，那就是按时完成。假设您确信自己拥有应该构建的东西。并假设其他人依赖它在特定日期上线。几个世纪以来，艺术家们都知道按时完成的秘诀。在下一章中，我们将学习如何将它应用到软件中。

There’s one last challenge that seems to plague software development, and that’s finishing on time. Suppose you’re confident that you have something that should be built. And suppose others are depending on it going live on a specific date. There’s a secret to finishing on time that’s been known by artists for centuries. In the next chapter, we’ll learn how to apply it to software.

为了构建这个新功能，这两个人需要与他们的团队建立共识。他们的团队需要能够指出问题和改进的可能性，并估计需要多长时间。这就是他们制作这张最终地图的目的。他们用它来讲述这个功能的故事——从用户的角度一步一步地讲。注意到注入地图的印刷屏幕了吗？他们在浏览地图时指着屏幕并突出显示细节，以便听众可以更好地设想解决方案。迪斯尼使用故事板浏览电影的人对这些人一无所知。

To build this new feature, these two guys will need to build shared understanding with their team. Their team needs to be able to point out problems and possibilities for improvement, and to estimate how long it’s going to take. That’s what they built this final map for. They used it to tell the feature’s story—step by step, from the user’s perspective. Notice the printed screens injected into the map? They pointed at screens and highlighted details while walking through the map so those listening could better envision the solution. The people at Disney who walk through movies using a storyboard have nothing on these guys.

当团队成员询问为什么屏幕会如此运行时，他们会讲述他们尝试过的变体以及用户的行为方式的故事。当团队询问有关输入数据或提交信息时到底发生了什么的详细问题时，这些人已经考虑过并可以回答。或者，当他们不知道时，他们会与团队讨论想法，并在模型中的原型或便签纸上做笔记。他们甚至为他们没有想到的细节添加了一些便利贴，但团队做到了。Aaron 告诉我，团队发现了几个他和 Mike 永远不会发现的技术依赖关系。

When team members asked why the screen behaves as it does, they had stories to tell about variations they’d tried, and how users behaved. When the team asked detailed questions about exactly what happens when data is entered, or information submitted, these guys had given it thought and could answer. Or, when they didn’t know, they discussed ideas with the team, and made notes on the prototypes or sticky notes in the model. They even added a couple of sticky notes for details they hadn’t thought of, but the team did. Aaron told me that the team spotted several technical dependencies that he and Mike would never have found.

任何长期从事软件开发游戏的人都知道，最大的挑战之一是估计开发实际需要多长时间。我将让您了解良好估算的最保守秘密之一：

Anyone who’s been in the software development game for any length of time knows that one of the biggest challenges is estimating how long development will actually take. I’m going to let you in on one of the best-kept secrets of good estimation:

有许多方法有望提供更准确的估计。我不打算在这里介绍其中任何一个。但我会告诉你，如果构建软件的人彼此之间以及设想它的人之间没有共同的理解，那么它们都行不通。

There are lots of methods that promise to give more accurate estimates. I’m not going to cover any of those here. But I will tell you none of them work if the people building the software don’t have shared understanding with one another, and with those who envisioned it.

建立共同的理解不应该成为估算的秘密。所以你现在应该去告诉别人。

Building shared understanding shouldn’t be a well-kept secret about estimation. So you should go tell someone else right now.

Workiva 的团队在这一点上不能真正摆脱建设。他们不能像 Globo.com 在第 2 章中所做的那样把事情删掉，因为他们已经证实他们需要这一切。当他们制作原型时，他们能够削减很多并验证他们的解决方案对客户仍然有价值。但是，当你看他们的地图时，它被切成三片。

The team at Workiva can’t really get away with building less at this point. They can’t do what Globo.com did in Chapter 2 and cut things away, because they’ve already validated that they need it all. When they were prototyping, they were able to cut away a lot and validate that their solution was still valuable to customers. But, when you look at their map, it’s cut into three slices.

“他们为什么要关心？” 你可能会问。客户想要的三分之一有点像交付一辆跑车的三分之一。没有人能驾驶它。但 Mike 是产品负责人。在确定一个好的解决方案后，他不会走开。现在他的角色变了，有点像电影里的导演。拍摄每个场景时，他都必须在那里。他必须决定哪些场景应该先拍，哪些场景最后拍。他知道最终整部电影需要组合在一起，看起来像一个连贯的整体。

“Why would they care?” you might ask. A third of what the customers want is sort of like delivering a third of a sports car. No one could drive it. But Mike is the product owner. He doesn’t get to walk away after he’s identified a good solution. His role changes now, and he’s a bit more like a director in a movie. He’s got to be there as every scene is shot. And he’s got to decide which scenes should be shot first, and which scenes get shot last. He knows that in the end the entire movie needs to come together and look like one coherent whole.

因此，迈克与他的团队一起制定了一个发展计划。这就是他们所做的：他们将地图分成三个横切切片。

So Mike worked with his team to create a development plan. This is what they did: they sliced their map into three, crosscutting slices.

第一个切片贯穿整个功能。一旦他们构建了所有这些部分，他们就可以看到端到端的功能。它不会在所有需要的情况下工作，如果他们以这种方式运送给用户，那些用户会嚎叫。但是 Mike 和他的团队将能够看到软件端到端地运行。他们将能够将真实数据放入其中以查看其性能如何，并且他们可以对其应用一些自动化测试工具以查看其扩展性如何。他们可以学到很多关于以后可能会给他们带来麻烦的技术风险。他们可以更有信心继续前进，他们将能够按时发布。或者，至少他们会发现会减慢他们速度的不可预见的挑战。我将第一个切片称为功能性行走骨架——这是我从 Alistair Cockburn 那里借来的一个术语。我听说其他人称其为“钢丝”或“曳光弹”。

The first slice cuts all the way through the functionality. Once they build all those pieces, they can see the functionality working from end to end. It wouldn’t work in all the situations it needs to, and if they shipped to users this way, those users would howl. But Mike and his team will be able to see the software running end to end. They’ll be able to put real data in it to see how well it performs, and they could apply some automated testing tools to it to see how well it scales. They can learn a lot about the technical risks that might cause them trouble later on. They can be more confident going forward that they will be able to release on time. Or, at least they’ll spot the unforeseen challenges that would slow them down. I call this first slice a functional walking skeleton—a term I borrowed from Alistair Cockburn. I’ve heard others call this a “steel thread” or a “tracer bullet.”

他们将在第二个切片上分层以构建功能——使其更接近可发布。在此过程中，他们可能会学到一些他们无法预料的事情。他们可能忽略了此功能应具有的一些特征——原型中未探索的更细微之处。他们可能已经发现系统没有按照他们预期的方式运行，需要做一些额外的工作才能获得他们想要的速度。这些是“可预测的不可预测的”——一个与唐纳德拉姆斯菲尔德的“未知的未知数”密切相关的概念。不要假装它们不存在。你知道他们这样做。

They’ll layer on the second slice to build up the functionality—to get it closer to releasable. Along the way, they’re likely to learn some things they couldn’t predict. They may have overlooked some characteristics this feature should have—finer points that weren’t explored in the prototype. They may have found that the system just doesn’t perform the way they expected and some extra work will need to be done to get the speed they want out of it. These are the “predictably unpredictables”—a concept closely related to Donald Rumsfeld’s “unknown unknowns.” Don’t pretend they don’t exist. You know they do.

最后，他们将在第三个切片上分层以优化特征，使其尽可能完美。他们还会添加一些不可预知的东西。

Finally, they’ll layer on the third slice to refine the feature, to make it as polished as it can be. They’ll also add in some of those unpredictable things.

这些切片中的每一个都不是对客户和用户的发布：它是团队成员用来停下来评估他们所处位置的里程碑。从用户和客户的角度来看，它是不完整的，所以不要让自己感到尴尬。

Each of these slices isn’t a release to customers and users: it’s a milestone the team members will use to stop and take stock of where they are. From a user and customer perspective it’s incomplete, so save yourselves the embarrassment.

Mike 和 Aaron 的团队估计此功能大约需要两个月的工作。像埃里克一样，他们使用两周的冲刺，所以他们需要四次冲刺。我猜他们本可以做四片，每个冲刺一个，但他们并没有那样想。你也不应该。将这些切片想象成三个不同的桶，每个桶都有不同的学习目标。决定他们将在时机成熟时进入哪些冲刺或迭代。

Mike and Aaron’s team estimated this feature to be about two months’ worth of work. Like Eric, they used two-week sprints, so it would take them four sprints. I guess they could have made four slices, one for each sprint, but they weren’t thinking of it that way. And you shouldn’t, either. Think of these slices as three different buckets with different learning goals for each. Decide which sprints or iterations they’ll go into when the time comes.

有一件事似乎是秘密，但实际上不应该是秘密，那就是估计是……估计的。访问 Web 并找到任何矛盾修辞法列表。我相信您会在那里找到这个术语：准确估计。如果我们确切地知道事情需要多长时间，那么我们就不会称其为估算，对吗？

One thing that seems to be a secret, but really shouldn’t be, is that estimates are…estimated. Hit the Web and find any list of oxymorons. I’m confident you’ll find this term there: accurate estimate. If we knew exactly how long things would take, then we wouldn’t have called it an estimate, would we?

但是，如果您构建少量软件，您可以非常确定的一件事是构建它们花费了多长时间。这就是所谓的测量，而且要准确得多。

But if you build little bits of software, one thing you can be pretty sure of is how long they took to build. That’s called measurement, and that’s quite a bit more accurate.

好吧，这是另一个秘密：你测量得越频繁，你的预测就越好。如果你每天上下班，我怀疑你很擅长预测需要多长时间。如果我问你到达大致相同区域的不同地址需要多长时间，我敢打赌你可以预测在正负 10 分钟内通勤需要多长时间。这就是估算的工作方式。

Ok, so here’s the other secret: the more frequently you measure, the better you get at predicting. If you commute to work every day, I suspect you’re pretty good at predicting how long it’ll take. If I asked you how long it’d take to get to a different address in roughly the same area, I’ll bet you could predict how long commuting there would take within plus or minus about 10 minutes. That’s the way estimation works.

通过将大事物分割成小事物，我们可以获得更多的衡量机会。当然，这有一些微妙之处，但作为一般原则，如果您有更多关于构建类似事物所花费时间的示例，您将获得更好的预测。

By slicing large things into small things, we get more opportunities to measure. Of course, there’s some subtlety to this, but as a general principle, you’ll get better predictions if you’ve got more examples of how long similar things have taken to build.

作为产品负责人，Mike 最终要按时发布此功能。他是一个优秀的产品负责人，所以他帮助他的小团队中的每个人也对这个目标负起责任。他将这些早期估计视为他的交付预算。

As a product owner, Mike is ultimately on the hook for getting this feature released on time. He’s a good product owner, so he helps everyone in his small team take some ownership of that goal too. He treats these early estimates as his delivery budget.

Mike 和 Aaron 与他们早期信任的开发人员一起工作，以获得初步的时间估算。他们将其视为预算。他们积极管理它。

Mike and Aaron worked together with developers they trust early on to get an initial time estimate. They treat it as a budget. And they actively manage it.

对于团队构建的每一小块，他们可以衡量构建该块所花费的时间。他们将自己建造的东西视为超出预算的开支。他们可能会发现他们已经完成了预算时间的一半，但只完成了构建功能的三分之一。当然，他们没有预料到这一点，但现在他们意识到了，并且可以为此做点什么。他们可以从他们正在开发的其他功能中借用一些预算。或者，他们可以对不会显着改变用户获得的好处的功能进行小的更改。或者他们可以面对现实，看看他们能做些什么来改变他们承诺交付给的人的期望。

With every small piece the team builds, they can measure how long that piece took to build. They treat what they’ve built as spending against their budget. They may find that they’re halfway through their budgeted time, but only a third of the way through building the feature. Certainly they didn’t expect that, but now they’re aware and they can do something about it. They could borrow some budget from other features they’re working on. Or there may be small changes they could make to the feature that won’t substantially change the benefit users get. Or they could just face the music and see what they can do to change expectations with the people they’ve promised delivery to.

根据情况的严重程度，他们可能都需要更多啤酒。

Depending on how bad it is, they may all need more beer.

在制定发展战略时，他们会尽早解决可能超出预算的问题。这些都是有风险的事情。与整个团队的对话有助于发现他们。

When slicing out a development strategy, they’ll look to tackle the things that may blow their budget as early as possible. Those are the risky things. And it’s conversations with the whole team that help spot them.

在故事地图中暴露风险

克里斯·辛克尔，SEP

Chris Shinkle, SEP

一家大型安防公司着手为中等规模的建筑物（例如，学校、医生办公室、零售店等）构建一个中等价位的无线门禁系统。该公司聘请 SEP 开发锁内的固件以及与之通信的无线 ZigBee 网关。

A large security company set out to build a mid-price-point, wireless, access control system for medium-size buildings (e.g., schools, doctors’ offices, retail, etc.). The company hired SEP to develop the firmware within the locks as well as the wireless ZigBee gateway with which they communicated.

该项目在技术上令人兴奋，但具有导致失败的所有因素，包括预算不足、时间紧迫、中游领导层变动、未经测试的技术以及大量的范围膨胀。

The project was technically exciting, but had all the ingredients for failure, including skimpy budget, tight timeline, midstream leadership changes, untested technology, and tons of scope bloat.

当然，事情很快就水落石出了。项目团队错过了几个里程碑。客户不高兴，团队士气低落。在回顾中，该团队发现错过日期的最大驱动因素是计划外工作，主要是由于不确定性和已实现的风险。有些东西需要改变。

Of course, things quickly began to unravel. The project team had missed several milestones. The client was unhappy and team morale was low. During a retrospective, the team discovered the biggest driver for missing dates was unplanned work, mostly due to uncertainties and realized risks. Something needed to change.

与任何聪明的工程师团队一样，该团队直面问题。他们的解决方案？修改故事地图。

Like any group of smart engineers, the team tackled the problem head on. Their solution? Modify the story map.

在高层次上，他们增加了故事地图的频率和保真度。通过在每次临时发布时增加故事映射的频率，他们怀疑他们会增加识别更多风险的可能性。通过增加地图的保真度以包括“风险故事”（除了正常的活动、任务和细节），他们怀疑他们能够可视化、讨论和更好地管理风险。

At a high level, they increased the frequency and fidelity of their story map. By increasing the frequency of story mapping at each interim release, they suspected they would increase the likelihood of identifying more risks. By increasing the fidelity of the map to include “Risk Stories” (in addition to normal Activities, Tasks, and Details), they suspected they would be able to visualize, discuss, and better manage the risks.

结果令人震惊。

The results were astounding.

该团队知道，典型故事地图的宽度和深度可以让人了解项目规模。他们还知道通过地图的路径数量是复杂性的一个很好的指标。但是，由于不确定性和风险之前没有反映在故事地图中，地图没有描述要完成的实际工作量（包括学习）。

The team knew that the width and depth of a typical story map gave a sense of the project size. They also knew the number of paths through the map was a good indicator of complexity. But, since uncertainty and risk weren’t previously reflected in the story map, the map didn’t depict the actual amount of work (including learning) to be done.

带有风险故事的新地图更好地描绘了前方道路的规模和复杂性。项目规模和复杂性得到了更好的体现，因为它们既包括原始的已知故事，也包括新的“未知故事”——风险，或者团队需要获得的知识，以便自信地继续已知故事。

The new map, with Risk Stories, gave a better picture for the size and complexity of the road ahead. Project size and complexity were better represented, because they were composed of both the original known stories as well as the new “unknown stories”—the risks, or the knowledge the team needed to gain to confidently move ahead with the known stories.

如您所料，故事地图对于规划变得更加有用。它现在强调了团队需要时间的风险和不确定性。将这段时间纳入计划的能力使团队更加可预测和可靠。

As you’d expect, the story map became much more useful for planning. It now highlighted risks and uncertainties that would need time from the team. The ability to incorporate that time into planning made the team much more predictable and reliable.

附带的好处包括一种衡量和更新利益相关者学习情况的切实方法。结合传统的功能燃尽图，该团队包括了风险燃尽图。当功能燃尽看起来不太好时，查看风险燃尽数据对客户特别有帮助。

Side benefits included a tangible way to measure and update stakeholders on learning. In conjunction with the traditional feature burn-down chart, the team included a risk burn-down chart. It was particularly helpful for the customer to see the risk burn-down data when the feature burn-down didn’t look great.

一天结束时，团队了解到增加故事地图的创建频率和添加新的风险故事是让地图更好地反映现实的有效方法。

At the end of the day, the team learned that increasing the frequency of story map creation and adding new Risk Stories are powerful ways to make your maps better reflect reality.

达芬奇会做什么？

What Would da Vinci Do?

我经常这样问自己。好吧，我真的不知道。但也许我应该。

I often ask myself that. OK, I don’t really. But maybe I should.

Mike 和 Aaron 所做的是遵循艺术家使用的及时完成的​​策略。这是我多年来一直使用的软件。而且，当我第一次在 Globo.com 遇到我的朋友时，我发现他们正在使用它，因为正如我之前提到的，如果他们迟到了为奥运会提供很酷的新互动内容，奥林匹克委员会将不会重新安排奥运会. 我想这个策略是您甚至不假思索地经常使用的策略。

What Mike and Aaron have done is to follow a strategy used by artists to finish in time. It’s one I’ve used for years with software. And, when I first met my friends at Globo.com, I found it’s one they use, because as I mentioned before, if they’re late with cool, new interactive stuff for the Olympics, the Olympic committee won’t reschedule the Olympics. I’ll guess this strategy is one you even use routinely, without thinking.

让我先解释一下达芬奇不做什么。但是，不幸的是，这往往是人们构建软件确实尝试做的事情。

Let me first explain what da Vinci doesn’t do. But, unfortunately, it’s too often what people building software do try to do.

假设你是达芬奇，你想创作一幅画，并且正在按照一个天真的软件团队的方式工作。^{[ 7 ]}你可以从你认为在你的脑海中清晰的画面开始。然后你把这幅画分成几个部分。假设你有五天的时间来画这幅画。每天你都会画更多的部分。在第五天结束时，Huzzah！——你完成了！什么可以更简单？

Suppose you were da Vinci, and you wanted to create a painting and were working the way a naïve software team does.^[7] You might start with what you believe is a clear vision of the painting in your mind. Then you break up the painting into its parts. Let’s say you had five days to paint this painting. Every day you’d paint more parts. At the end of day five, huzzah!—you’re done! What could be simpler?

只是，它不是那样工作的——至少对艺术家来说不是这样。这种创造事物的方式假设我们的愿景是正确和准确的。它还假设了一些关于创作者的技能以及她在不在上下文中看到它们的情况下精确定义零件的能力。如果你在软件开发中这样做，它被称为增量策略。这就是瓦匠砌墙的方式。如果每一块都像砖一样有规则的大小和明确的定义，它就会起作用。

Only, it doesn’t work like that—at least not for artists. This way of creating things assumes our vision is correct and accurate. It also assumes something about the skill of the creator and her ability to precisely define parts without seeing them in context. If you do this in software development, it’s called an incremental strategy. It’s the way a bricklayer might build a wall. And it works if each piece is as regularly sized and well defined as a brick.

当我小时候画画的时候，我就掉进了这个陷阱。我经常画某种动物，然后从头开始。我会一直画到完美为止，然后继续画身体的其余部分——腿、尾巴等等。当我接近完成时，我可以看到我的动物的比例有点不对劲。头部对于身体的其他部分来说太大或太小。腿似乎扭曲成一个奇怪的角度。而这个生物的姿势似乎有点僵硬。至少，这是我作为一个才华横溢的六岁孩子的看法——所有六岁的孩子都是才华横溢的艺术家。

When I used to draw as a kid, I fell into this trap. I’d often be drawing some sort of animal and start with the head. I’d work on that ‘til it was perfect, then continue to draw the rest of the body—legs, tail, and so on. By the time I got close to done, I could see that the proportions of my animal had gotten a bit off. The head was too big, or too small for the rest of the body. The legs seem to be twisted at an odd angle. And the pose of the creature just seemed a bit stiff. At least, that was my perspective as a talented six-year-old—and all six-year-olds are talented artists.

晚年我才知道先画整个构图对我有好处。从那里我可以得到正确的比例，并改变生物的姿势。我什至可能会重新考虑我要画什么。

It was later in life that I learned I’d benefit from sketching the whole composition first. From there I could get proportions right, and make changes to the pose of the creature. I’d maybe even reconsider what I was going to draw.

我没有和达芬奇在一起，但我希望他也做了同样的事情。

I wasn’t there with da Vinci, but I expect he did something much the same.

甚至达芬奇也可能承认他的远见并不完美，并且他在创作这幅画时会学到一些东西。第一天，我想他先画了构图草图，或者可能画了淡淡的底色。我可以想象他此时正在改变构图。“嘿，我认为微笑将是一个重要的部分。我会把她的手从嘴里移开。背景中的那些山脉……太多了。”

Even da Vinci would probably acknowledge that his vision wasn’t perfect, and that he’d learn something as he was creating the painting. On day one, I imagine he first sketched the composition, or maybe did a light underpainting. I can imagine him at this point making changes to the composition. “Hey, I think the smile is going to be an important part. I’ll move her hand away from her mouth. And those mountains in the background…too much.”

到周中，达芬奇为这幅画添加了许多颜色和形式，但他仍在不断地进行修改。到周末时，他知道自己的时间不多了，所以他所有的精力都转移到了完善这幅画上。有人想知道蒙娜丽莎没有眉毛是故意的选择，还是达芬奇只是没时间添加一个新的、完全精致的特征。

By midweek, da Vinci is adding lots of color and form to the painting, but he’s still making changes as he goes. By the end of the week, he knows he’s running out of time, so all his effort shifts to refining the painting. One wonders if the Mona Lisa missing her eyebrows was a deliberate choice, or if da Vinci simply ran out of time to add a new, fully refined feature.

伟大的艺术永远不会完成，只会被抛弃。— 列奥纳多·达·芬奇

Great art is never finished, only abandoned. — Leonardo da Vinci

这句话出自达芬奇之手，它表达了我们可以永远继续添加和完善的概念，但在某些时候，我们需要交付产品。而且，如果达芬奇的作品和许多其他艺术家的作品都是很好的例子，那么我们——欣赏作品的人——不知道它被遗弃了。对我们来说，它看起来已经完成了。

That quote is attributed to da Vinci, and it speaks to the notion that we could continue to add and refine forever, but that, at some point, we need to deliver the product. And, if da Vinci’s work and that of lots of other artists are good examples, we—the people who appreciate the work—have no idea it was abandoned. To us, it looks finished.

艺术家或作家就是这样工作的。事实上，制作早报或晚报的人就是这样工作的。创造现场戏剧的人就是这样工作的。任何必须在截止日期前交付并边做边学的人都认可这种策略。

An artist or author works this way. In fact, the people who put together the morning paper or evening news work this way. The people who create live theater work this way. Anyone who must deliver on a deadline, and learn as he goes, recognizes this strategy.

在软件开发中，迭代有两个含义。从过程的角度来看，就是一遍又一遍地重复同样的过程。这就是为什么敏捷开发中使用的开发时间盒通常被称为迭代的原因。但是当你使用这个术语来描述你正在用你构建的软件做什么时，它意味着评估和改变它。在构建之后更改软件通常被视为失败。在这里，糟糕的需求或范围蔓延等术语被用来谴责那些决定构建什么的人。但我们都知道，改变是学习的必然结果。

In software development, iterate has two meanings. From a process perspective, it means to repeat the same process over and over. That’s why the development time-box used in Agile development is often called an iteration. But when you use this term to describe what you’re doing with the software you build, it means to evaluate and change it. And changing software after it’s built is too often seen as a failure. It’s where terms like bad requirements or scope creep get used to reprimand the people who made decisions about what to build. But we all know that change is a necessary result of learning.

不幸的是，我们很容易陷入迭代的漩涡中。所以我们必须密切关注日历并不断增加更多内容。艺术家不仅通过在绘画中添加全新的东西来添加更多，而且还通过构建已经添加的东西来添加更多。

Unfortunately, we can easily get trapped in the whirling eddies of iteration. So we’ve got to keep our eye on the calendar and keep incrementally adding more. The artist adds more not only by adding whole new things to a painting, but also by building up things that were already added.

您可以通过首先创建一个没有任何额外功能的简单版本来在软件中做同样的事情。您可能会认为这是您的草图。使用简单版本后，您可以通过向其添加更多功能来构建它。随着时间的推移，它逐渐成为您和其他人最初设想的最终版本。如果事情进展顺利，它会构建出与您最初预想不同的东西，但会更好，因为它会受益于您所学到的知识。

You might do the same things in software by first creating a simple version of functionality without any extras. You might think of this as your sketch. After using the simple version, you’d build it up by adding more functionality to it. Over time, it builds up to be the finished version you and others may have originally envisioned. If things go really well, it builds up to something different than you originally envisioned, but better because it benefits from what you’ve learned.

这可能会让你有点头疼，但我会在这里混合一些比喻。在创建软件时，我个人依赖基于国际象棋比喻的策略。我是一个几乎不会下棋的废棋手，所以如果我用错了这个比喻，你不准给我写信和纠正我。无论产品或功能发布多小，我都喜欢将我的发布积压分为三组：

This may hurt your head a bit, but I’m going to mix some metaphors here. I personally rely on a strategy based on a chess metaphor when creating software. I’m a crap chess player who barely knows how to play the game, so if I’m misusing the metaphor, you’re not allowed to write me and correct me. No matter how small the product or feature release, I prefer to slice my release backlog into three groups:

如果您已经发现了您认为对客户和用户而言可行的首次发布，那么作为一个团队一起工作，将首次公开发布再次分成开场游戏、中期游戏和结束游戏故事。创建产品的团队最擅长识别风险和学习机会所在的位置。他们会对共同制定的计划产生强烈的主人翁意识。

If you’ve discovered what you believe is a viable first release to customers and users, work together as a team to slice that first public release again into opening game, mid game, and endgame stories. The team creating the product is best at identifying where the risks and opportunities to learn are. They’ll feel the strongest ownership over the plan they create together.

这就是 Aaron 和 Mike 在他们整个开发团队的帮助下所做的。再看看他们多开心。

That’s what Aaron and Mike did with the help of their whole development team. Look again at how happy they are.

在第 3 章中，埃里克不得不应对识别错误产品的风险。他采用了一种拆分发布的策略，使他能够将整个产品呈现在客户面前。

In Chapter 3, Eric had to deal with the risk of identifying the wrong product. He used a strategy of slicing out releases that allowed him to put whole products in front of customers.

在本章中，Aaron 和 Mike 专注于技术风险，这些风险可能会破坏他们的交付计划或导致该功能的成本远远超过他们的预期。他们不会在每个周期结束时向客户和用户展示他们最终得到的结果，因为他们已经知道这还不够。但是他们会自己和他们的团队认真认真地审视它，并使用他们学到的知识来安全地引导此功能的开发。

In this chapter, Aaron and Mike are focused on technical risk, the things that might blow their delivery schedule or cause the feature to cost much more than they expected. They won’t show what they end up with at the end of every cycle to customers and users because they already know it’s not sufficient. But they’ll take a good, hard look at it themselves and with their team, and use what they learn to safely steer the development of this feature.

这很微妙，但您可能已经在第 2 章中发现，Eric 进行了两次为期两周的冲刺，以构建他的下一个最小可行产品实验。他必须决定在第一个冲刺中构建哪些东西，在第二个冲刺中构建哪些东西。他用这种思维来做出那些决定。他和他的团队把有风险的部分放在首位——Eric 或他的团队希望尽快看到工作的部分，以便他们可以在将其呈现给客户之前纠正路线。

It’s subtle, but you might have caught in Chapter 2 that Eric was taking two two-week sprints to build his next minimum viable product experiment. And he had to decide which things to build in the first sprint, and which to build in the second sprint. He used this kind of thinking to make those decisions. He and his team put the risky bits first—the parts that Eric or his team wanted to see working sooner so that they could course-correct before they put it in front of their customers.

您已经看到了为不同目的构建和使用地图的四个非常好的示例。我们将在后面的章节中探讨更多使用地图的方法。但在你走得太远之前，我想向你展示我最喜欢的教别人如何绘制地图的技巧。我保证，如果您尝试一下，从那一刻起您就会像专家一样绘制地图。

You’ve seen four pretty good examples of building and using maps for different purposes. There are a lot more ways to use maps that we’ll explore in later chapters. But before you get too far, I want to show you my favorite trick for teaching others how to map. I promise if you try it, you’ll map like an expert from that moment on.

让我们从第 5 章开始。

Let’s pick up there in Chapter 5.

闭上眼睛，回想你今早醒来的那一刻。你今天早上确实醒了，对吧？你记得做的第一件事是什么？现在，睁开眼睛，把它写在便利贴上。我会和你一起写。我的第一张便利贴上写着，“打瞌睡。” 不幸的是，通常是这样。在糟糕的早晨，我可能不得不打两三下。

Close your eyes, and think back to the moment you woke up this morning. You did wake up this morning, right? What’s the first thing you recall doing? Now, open your eyes, and write it down on a sticky note. I’ll write along with you. My first sticky note says, “Hit snooze.” Unfortunately, it usually does. On bad mornings I may have to hit it two or three times.

现在，撕掉那张胶粘物，把它放在你面前的桌子上。然后，想想你接下来做的事情。知道了？现在，把它写在下一张便利贴上，撕下，贴在第一张便利贴旁边。然后继续。我接下来的几张即时贴上写着，“关掉闹钟”和“跌跌撞撞地去洗手间”。

Now, peel off that sticky and put it on the table in front of you. Then, think of the next thing you did. Got it? Now, write it on the next sticky, peel it off, and place it next to the first one. Then keep going. My next couple of stickies say, “Turn off alarm” and “Stumble to the bathroom.”

继续写便签，直到你准备好工作，或者无论你今天在做什么。我通常以“上车”结束，开始开车上班。我预计您需要三四分钟才能写完所有便签。

Keep writing sticky notes until you’ve gotten ready for work, or whatever you’re doing today. I usually end with “Get into my car” to start my drive for work. I expect it’ll take you three or four minutes to write all your stickies.

我的任务与你的不同

My Tasks Are Different Than Yours

我相信这不会让您感到惊讶，但人与人之间是不同的。您会在他们选择做事的方式上看到这些差异。

I’m sure this doesn’t come as a surprise to you, but people are different from one another. You’ll see these differences expressed in the way they choose to do things.

例如，有些人几乎每天早上都有锻炼的动力和自律。如果你写了几个与锻炼相关的任务，那你太棒了！我自己仍在努力。

For instance, some people have both the motivation and self-discipline to exercise almost every morning. If you wrote a couple of tasks related to exercise, you rock! I’m still working on that myself.

有些人只是因为他们居住的家庭而承担了更多的责任。如果你有孩子，我保证你会写下一些没有孩子的人没有的任务。如果你有一只狗，你可能会有一两个任务专门用来照顾这只狗。

Some people simply have more responsibilities because of the household they live in. If you’ve got kids, I promise you wrote down several tasks that people without kids didn’t. If you have a dog, you may have a task or two dedicated to taking care of the dog.

当您考虑使用您的软件的人时，请记住这一点。他们在使用它时可能有不同的目标。他们可能会在不同的环境中使用它，迫使他们考虑其他人或事物。

Keep that in mind when you’re thinking about people using your software. They may have different goals when using it. They may use it in different contexts that force them to take into account other people or things.

我只是更注重细节

I’m Just More Detail-Oriented

在这个练习中，有些人只是写了比其他人更多的细节。他们可能会说“做早餐”之类的东西，而不是写“把面包放进烤面包机”、“倒一杯果汁”，或者，如果你是我妻子的话，“在冰沙里加羽衣甘蓝”，这是其中一个我真的很讨厌她做的任务。

In this exercise, some people just write a lot more details than others. They might take something like “Make breakfast” and instead write “Put bread in the toaster,” “Pour a glass of juice,” or, if you’re my wife, “Add kale to the smoothie,” which is one of the tasks I really hate her doing.

任务就像石头。如果你拿一块大石头用锤子敲它，它会碎成一堆小石头。那些较小的岩石仍然是岩石。任务也是一样。现在我不知道什么时候石头大到可以称为巨石，什么时候小到可以称为鹅卵石，但是有一种很酷的方法可以区分大任务和小任务。

Tasks are like rocks. If you take a big rock and hit it with a hammer, it’ll break into a bunch of smaller ones. Those smaller rocks are still rocks. It’s the same thing with tasks. Now I don’t know when a rock is big enough to be called a boulder, or small enough to be called a pebble, but there’s a cool way to tell a big task from a small task.

我的朋友 Alistair Cockburn 描述了目标水平的概念在他的书Writing Effective Use Cases (Addison-Wesley Professional) 中。别担心，我们不会开始编写用例。只是当我们谈论人类行为时，这个概念真的很有用。

My friend Alistair Cockburn described the goal level concept in his book Writing Effective Use Cases (Addison-Wesley Professional). Don’t worry, we’re not going to start writing use cases. It’s just that the concept is really useful when we’re talking about human behavior.

阿利斯泰尔使用海拔比喻，海平面在中间，其他一切要么高于海平面，要么低于海平面。海平面任务是我们希望在有意停下来做其他事情之前完成的任务。您是否在任务列表中写下了“洗澡”？这是一项海平面任务，因为您不会在淋浴进行到一半时想，伙计，这场淋浴正在拖延。我想我会喝杯咖啡，稍后再洗完澡。Alistair 称这些功能级任务并用一点海浪来注释它们。但我只是称它们为任务。

Alistair uses an altitude metaphor where sea level is in the middle, and everything else is either above or below sea level. A sea-level task is one we’d expect to complete before intentionally stopping to do something else. Did you write “Take a shower” in your list of tasks? That’s a sea-level task because you don’t get halfway through your shower and think, Man, this shower is dragging on. I think I’ll grab a cup of coffee and finish this shower later. Alistair calls these functional-level tasks and annotates them with a little ocean wave. But I’ll just call them tasks.

像“洗澡”这样的任务会分解成许多更小的子任务，比如“调节水温”和“洗头”，如果你是我妻子，还有一些涉及丝瓜去角质的东西。请记住，人是不同的，您会在他们处理任务的方式上看到行为差异。阿利斯泰尔用一条小鱼来注释这些，因为它们在海底。

Tasks like “Take a shower” break down into lots of smaller subtasks like “Adjust water temperature” and “Wash hair,” and, if you’re my wife, something involving an exfoliating loofah thing. Remember, people are different, and you’ll see behavior differences in the way they approach tasks. Alistair annotates these with a little fish because they’re below the ocean.

最后，我们可以将一堆任务汇总成一个摘​​要级任务。淋浴、刮胡子、刷牙，以及早上起床后所做的所有其他事情都可以归结为一项摘要任务。不过，我不确定我会怎么称呼它。“收拾干净了吗？” “早上沐浴？” 沐浴是一个愚蠢的词。不要用那个。

Finally, we could roll up a bunch of tasks into a summary-level task. Taking a shower, shaving, brushing teeth, and all that other stuff you do in the morning after you get out of bed could roll up into a summary task. I’m not sure what I’d call it, though. “Getting cleaned up?” “Morning ablutions?” Ablutions is a silly word. Don’t use that.

使用目标级别的概念来帮助您聚合小任务或分解大任务。

Use the goal-level concept to help you aggregate small tasks or decompose large tasks.

如果您还没有这样做，请按照从左到右的顺序组织您的任务，先做的在左边，后来做的在右边。

If you haven’t done this already, organize your tasks in a left-to-right flow with what you did first on the left, and what you did later on the right.

试着讲一个故事，指着第一个便利贴说，“首先我做了这个，”然后指着下一个便利贴说，“然后，我做了这个。” 现在继续从左向右移动并讲述您的故事。你可以看到每个便利贴都是一个步骤，隐藏在每个便利贴之间的是漂亮的连词“……然后我……”

Try telling a story by pointing at the first sticky note and saying, “First I did this,” and then pointing to the next sticky and saying, “then, I did this.” Now keep going moving from left to right and telling your story. You can see that each sticky note is a step, and hidden in between each sticky note is the nifty little conjunction phrase “…and then I…”

我将这种从左到右的顺序称为叙事流程，它是“讲故事顺序”的一种奇特说法。我们将把这整个东西称为地图并且叙事流是它的从左到右的轴。

I’ll call this left-to-right order the narrative flow, which is a fancy way of saying “storytelling order.” We’ll call this whole thing a map and that narrative flow is its left-to-right axis.

哇，我的流量变得非常广泛。我开始堆叠同时发生的事情。当我布置流程时，我发现我已经错过了一些细节，我正在尝试确定它们是否重要。

Wow, my flow got pretty wide. I started stacking things that happen in and around the same time. As I lay out the flow, I see I already missed a few details, and I’m trying to decide if they matter.

到目前为止，这是显而易见的，对吧？学习这个几乎不值得你浪费纸张。但是等等，它会变得有趣。

So far this is dead obvious, right? Learning this was hardly worth the paper you’re wasting. But wait, it’s about to get interesting.

花点时间想想你昨天早上做了什么。如果你昨天早上做的事情和今天早上做的不一样，把它们写下来并添加到你的地图上。

Take a minute and think about what you did yesterday morning. If there are different things you did yesterday morning than you did this morning, write them down and add them to your map.

想想事情出错的早晨。如果没有热水怎么办？你当时做了什么？如果你没有牛奶或麦片或任何你通常早餐吃的东西怎么办？如果您的女儿因为忘记完成今天要交的家庭作业而陷入恐慌怎么办，这是我家时不时发生的事情。然后呢？为您要执行的操作编写任务并将其添加到地图中。

Think of mornings when things went wrong. What if there was no hot water? What did you do then? What if you were out of milk or cereal or whatever you normally eat for breakfast? What if your daughter flew into a panic because she forgot to do her homework that’s due today, which is what happens in my house every once in a while. Then what? Write tasks for what you’d do and add them to the map.

现在，想想你理想中的早晨。什么会让你的早晨变得完美？对我来说，就是做点运动，享受一顿丰盛的早餐，同时继续阅读。但那样我就得早点起床，停止打瞌睡。

Now, think about your ideal morning. What would make your morning perfect? For me, it would be getting some exercise and enjoying a long breakfast while I catch up on some reading. But then I’d have to get up a lot earlier and stop hitting snooze.

另请注意，您需要将一些任务放在一列中，这既是为了节省空间，也是因为它们看起来与您通常可能执行的其他任务相似。例如，您可能会发现自己有做一顿非常棒的早餐的任务，您可以将这些任务与通常做的快速早餐的任务一起放在一个列中。

Notice also that you’ll want to put some tasks in a column, both to save space and because they seem similar to other tasks you might normally do. For example, you might find that you’ve got tasks for making a really great breakfast that you can put in a column along with the tasks for making the quick breakfast you normally make.

我的朋友 David Hussman 称之为“玩什么”，你可能还记得第 2章和第 3章中的一个短语。不幸的是，我们可以玩很长时间的 What-About 并使这张地图变大。我在我的地图上添加了一些东西，专门用于我希望做的事情，比如锻炼身体或在早餐时做一些放松的阅读。我还添加了一些通常在早上发生的更常见的替代方案。

My friend David Hussman calls this “playing What-About,” a phrase you might remember from Chapter 2 and Chapter 3. Unfortunately, we could play What-About for a long time and make this map huge. I added a few more things to my map specifically for things I wish I’d done, like exercising or doing a bit of relaxing reading during breakfast. I also added a few more common alternatives that often happen in the morning.

到目前为止，您的地图应该看起来很宽，如果您已经探索了很多选项，可能会有点深。它可能有 30 个或更多任务。它看起来应该像某种奇怪动物的脊椎和肋骨。

By now, your map should be looking pretty wide, and if you’ve explored lots of options, maybe a little deep. It’ll likely have 30 or more tasks. It should look like the spine and ribs of a weird animal.

如果你退后一步，从左到右查看你的地图，你会发现有一堆故事似乎是连在一起的——例如，你在浴室里做的所有准备工作，或者所有这些事情在厨房里做早餐，或者检查天气，拿一件外套，把你的笔记本电脑或其他你在离开家之前需要的东西装在你的包里。你能看到那些似乎在一起帮助你实现更大目标的任务群吗？

If you step back a bit and look across your map from left to right, you’ll find there are bunches of stories that seem to go together—for instance, all those things you do in the bathroom to get ready, or all those things in the kitchen to make breakfast, or that junk you do to check the weather, grab a coat, and load your bag with your laptop or other stuff you’ll need before leaving the house. Can you see those clusters of tasks that seem to go together to help you reach a bigger goal?

在这些相似的便签簇中的每一个上方，放一张不同颜色的便签。在上面写一个简短的动词短语，提炼出它下面的所有任务。

Above each of these clusters of similar stickies, put a different colored sticky note. Write a short verb phrase on it that distills all the tasks underneath it.

如果你没有不同颜色的便利贴，我会告诉你一个秘密。每包便利贴都有两种形状！将便利贴旋转 45 度，噗，你得到了一个很酷的菱形。如果您想使粘性看起来不同，请使用它。

If you don’t have a different color of sticky note, I’ll let you in on a secret. Every package of sticky notes comes with two shapes! Rotate a sticky note 45 degrees and, poof, you’ve got a cool diamond shape. Use that if you want to make a sticky look different.

这些具有更高目标级别任务的便签称为活动。活动组织了由相似的人在相似的时间完成的一系列任务，以达到特定的目标。当您阅读地图顶部的活动时，它们也处于叙述流程中。一排便利贴是地图的主干。如果您有一张地图，里面有很多便签纸并且您想分享它，一个好的开始方法是讲一个高层次的故事。只需阅读地图的主干部分，每个活动之间都有“……然后他们……”连词。

These sticky notes with a higher goal-level task are called activities. Activities organize a bunch of tasks done by similar people at similar times in order to reach a particular goal. When you read the activities across the top of the map, they’re in a narrative flow, too. The row of stickies is the backbone of the map. If you’ve got a map with lots of stickies in it and you wanted to share it, a good way to start is by telling a high-level story. Just read the backbone of the map, with the “…and then they…” conjunction between each activity.

这是我的成长地图，其中添加了活动以赋予地图主干。它使阅读和查找内容变得更容易，至少对我而言。这让我更容易真正了解早上发生的事情。

Here’s my growing map with activities added to give the map a backbone. It makes it easier to read and find things, at least for me. And it makes it easier to really get the big picture of what’s going on in my morning.

活动似乎不像任务那样有共同语言。例如，您在离开家之前做的那件事叫什么？你收拾包包、查找购物清单、查看天气并在需要时带上雨伞的那种东西？我可以称之为“收拾垃圾”。你可能会称它为不同的东西。

Activities don’t seem to have common language the way tasks do. For instance, what do you call that thing you do before leaving the house? That thing where you gather up your bag, find a shopping list, check the weather, and grab an umbrella if you need it? I could call it “gathering up my junk.” You might call it something different.

当你为你的产品和你的客户构建这些时，你会想要他们怎么称呼它。

When you build these for your products and your customers, you’ll want to call it what they call it.

现在，这是非常酷的部分 — 您可以使用地图来帮助您想象未发生的事情的部分。

Now, here’s the really cool part—the part where you get to use the map to help you imagine something that didn’t happen.

如果您查看已构建的地图，您可能会在左侧边缘的某处看到“打瞌睡”或“关闭闹钟”。想象一下，今天早上你可以跳过那个。你可以跳过它，因为昨晚你忘记设置闹钟了。你猛地睁开眼睛，看了看你的时钟，你发现你需要在几分钟内到达某个地方。你真的来晚了！不要惊慌——我们只是在假装。

If you look at the map you’ve built, you’ll probably see “Hit snooze” or “Turn off alarm” somewhere on the left edge. Imagine that this morning you can skip that one. You can skip it because last night you forgot to set your alarm. Your eyes shot open and looked at your clock and you saw you needed to be somewhere in just a few minutes. You’re really late! Don’t panic—we’re just pretending.

在便利贴上写下“几分钟后出门”，并将其放在地图左侧靠近顶部的位置。现在，想象一条线从左到右穿过地图的中间——有点像腰带。现在，如果您不想在几分钟内完成离开的目标，请将所有任务移至该线下方。不要将活动向下移动，即使它们下面没有任务。让活动中没有任务可以让你表明你今天早上不会达到那个目标。

Write “Get out the door in a few minutes” on a sticky and place it to the left of the map near the top. Now, imagine a line slicing through the middle of the map left to right—kinda like a belt. Now, move all the tasks below that line if you wouldn’t do them to reach the goal of getting out in a few minutes. Don’t move the activities down, even if there are no tasks left under them. Having the activity with no tasks in it lets you show that you aren’t going to hit that goal this morning.

您可能只剩下顶部切片中的几个任务。现在返回流程并填写缺少的任务以及如果您迟到会做的任务。例如，你可能通常会洗澡，但当你迟到时，你会添加诸如“往脸上泼水”或“用毛巾清洗我身体特别臭的部位”之类的任务。当与一组开发人员一起做这个活动时，我经常看到任务“应用额外的除臭剂”。我不是在评判。我只是说。

You’ll likely be left with just a few tasks in the top slice. Now go back through the flow and fill in tasks that are missing and that you would do if you were late. For example, you might normally take a shower, but when you’re late you instead add in tasks like “Splash water on face” or “Use a washcloth to wash the particularly stinky parts of my body.” When doing this activity with a group of developers, I often see the task “Apply extra deodorant.” I’m not judging. I’m just saying.

这是我的切片地图，用于查找我需要在几分钟内出门的任务。

Here’s my map sliced to find the tasks I’ll need to get out the door in a few minutes.

您可以通过将不同的目标挂在左侧来尝试这个技巧。比如“度过一个最奢华的早晨”或“去度个两周的假期”。您会发现叙事流程保持相当持久，但您需要添加或删除任务以帮助您实现不同的目标。

You can try this trick by thinking of different goals to hang on the left side. Like “Have the most luxurious morning ever” or “Leave for a two-week vacation.” You’ll find the narrative flow stays pretty durable, but that you’ll need to add or remove tasks to help you reach that different goal.

那真的很容易，不是吗？在构建这张地图时，您了解到：

That was really easy, wasn’t it? As you built this map you learned that:

现在，我很确定你们中的很多人只是在阅读，而不是在阅读时真正映射。别以为我没注意到。但是，如果您是那些没有在早上绘制地图的懒鬼之一，请向我保证您会尝试一下。毫无疑问，这是我最喜欢的教授这些基本绘图概念的方式。如果您是在您的组织中第一次尝试映射，请召集一小群人并完成此练习。你们都将学习基础知识。而且您将能够很好地绘制任何东西。

Now, I’m pretty sure a great number of you were just reading along and not really mapping as you read. Don’t think I didn’t notice. But if you’re one of those slackers who didn’t map your morning, promise me you will try it. It’s hands down my favorite way of teaching these basic mapping concepts. If you’re trying out mapping for the first time in your organization, get a small group of people together and run through this exercise. You’ll all learn the basics. And you’ll be well on your way to being able to map anything.

工作前需要淋浴吗？

Rick Cusick，Reading Plus，威努斯基，佛蒙特州

Rick Cusick, Reading Plus, Winooski, Vermont

我们与四名开发人员、产品负责人、一名测试员、一名用户体验主管和两名产品培训师一起进行了早上的地图练习。我们分成两个小组，快速捕捉每个人的早晨，然后将我们各自的早晨分类并归类为“普通早晨”的单一表示。人们喜欢构建地图的工作，尽管他们以前从未做过或从构建我们自己的产品体验的角度考虑过它。

We ran the morning map exercise with four developers, the product owner, a tester, a UX lead, and two of our product trainers. Split into two teams, we captured each person’s morning rapidly, and then sorted and resorted our respective mornings into a single representation of what “an average morning” looked like. People enjoyed the work of building the map, even though they had never done it before or considered it in terms of building our own product’s experience.

我进行这项练习的目的是提高可视化我们工作的效率，展示如何将地图放在一起创造共同的理解，并利用以可访问的格式查看体验的价值。意想不到的好处是密切合作的效果——在一个项目中作为一个团队工作，目标通过工作本身来揭示——以及彼此产生同理心的时刻。“我不知道你每天都把孩子送到学校。” “你早上上班前做瑜伽吗？” “我不能不吃早饭——我会没用的！”

My goals in approaching the exercise were to promote the efficiency of visualizing our work, demonstrate how putting the map together created shared understanding, and leverage the value of seeing the experience in an accessible format. The unexpected benefits were the effects of close collaboration—working as a team on a project where the goal was revealed through the work itself—and the moments of empathy for one another. “I didn’t realize you dropped your kids off at school every day.” “You do yoga in the morning before work?” “I can’t go without breakfast—I’ll be useless!”

人们对同时发生的事件或因果关系感到困惑。“如果我边喝咖啡边看报纸，那是一两张便利贴吗？” “星期五，我妻子送孩子们上学，那我怎么表示呢？” 另一个挑战是担心从左到右的故事地图中时间的线性特性无法捕捉所有可能性。作为主持人，我发现在练习过程中看到这种思考的进展是令人欣慰的，即使我当时并没有得到所有的答案。

There was some confusion around events that happened simultaneously, or with causality. “If I read the paper while I’m drinking coffee, is that one or two sticky notes?” “On Fridays, my wife takes the kids to school, so how do I represent that?” The other challenge was a concern that the linear nature of time in a left-to-right story map wasn’t able to capture all possibilities. As the facilitator, I found it gratifying to see that kind of thinking in progress during the exercise, even if I didn’t have all the answers right then.

当我们优先考虑活动时，为了喜剧效果做出了一些艰难的选择。“上班前需要洗澡吗？” 是一个有趣的笑话，虽然有点恶臭。“不管我们还做了什么，我们都必须起床，穿好衣服，然后开车去上班，”一位参与者说，另一位参与者迅速说道，“除非你在家工作！”

As we prioritized activities, some hard choices were made to comic effect. “Do we need to shower before work?” is a funny if somewhat odiferous joke that popped out. “No matter what else we cut out, we have to wake up, get dressed, and drive to work,” observed one participant, with another quickly piping up, “Unless you are working from home!”

在此练习后不久，故事地图成为我们交流体验、确定用户故事优先级以及安排迭代和发布的首选方式。它已经进入了公司的本土文化和开发文化，并一直延续到今天。

Soon after this exercise, story maps became our preferred way to communicate an experience, prioritize user stories, and schedule iterations and releases. It had entered the company’s vernacular and the development culture, and continues through the present day.

我现在为我们组织中的多个团队进行同样的练习后学到的一个教训是使用破冰船来引导参与者的心态。通过让每个人只写下他或她在起床和上班之间所做的一件事来开始会议。然后让每个人回答这个问题：“你为什么采取那个行动？” 我发现这启动了一个背景心理线索，该线索出现在以后的计划会议中：“这个用户故事的价值是什么？为什么我们的用户会这样做？”

One lesson I learned, having run this same exercise now for multiple teams in our organization, is to use an icebreaker to prime the mindset of the participants. Start the session by having each person write just one thing he or she did between waking up and getting to work. Then ask each person to answer the question: “Why did you take that action?” I found that this starts a background mental thread that shows up in later planning sessions: “What is the value of this user story? Why would our users do this?”

我怀疑你们中的一些人注意到了这一点，但是您刚刚创建的地图与前四章中创建的地图有根本的区别。Gary、Globo.com、Eric、Mike 和 Aaron 创建的地图都设想了用户在未来将如何使用他们的产品——稍后，在产品交付之后。他们编写了他们想象中人们在产品中所做的任务和活动。但你创建的地图是关于你现在做事方式的地图——事实上，今天早上。而且，事实证明，两者的概念是相同的。所以请放心，我没有浪费你的时间。

I suspect a few of you caught this, but the map you just created has a fundamental difference from the maps created in the first four chapters. The maps Gary, Globo.com, Eric, and Mike and Aaron created all imagine how users will use their products in the future—later, after the product is delivered. They wrote tasks and activities that they imagined people doing in the product. But the map you created is a map about the way you do things now—this morning, as a matter of fact. And, as it turns out, the concepts are the same in both. So be relieved I haven’t wasted your time.

“现在的故事地图”的一个很酷的事情是你可以构建它们来更好地了解人们今天的工作方式。你这样做只是为了了解你今天早上是如何准备的。如果您返回并向地图添加其他内容，您可以了解更多信息。简单的添加是：

One of the cool things about “now story maps” is that you can build them to better understand how people work today. You just did this to learn how you got ready this morning. You can learn even more if you go back and add other things to the map. The easy things to add are:

用户体验社区中的许多人多年来一直在构建这些以更好地了解他们的用户。有时它们被称为旅程地图，但它们的基本思想相同。

Lots of people in the user experience community have been building these for years to better understand their users. Sometimes they’re called journey maps, but they’re the same basic idea.

2000 年代初，我在一家名为 Tomax 的小型产品公司领导团队。我们为实体零售商构建了软件——那些我们在把所有时间都花在网上之前经常去的购物场所。我们接待了一位经营大型油漆和室内装饰连锁店的新客户。现在，我们对零售业以及在销售点销售商品和管理库存的用户了解颇多，但有些事情我们并不知道，这些事情是油漆和装饰店特有的。例如，我们不知道如何销售定制有色油漆或定制百叶窗。我们必须快速学习。

In the early 2000s, I led a team at a small product company called Tomax. We built software for brick-and-mortar retailers—those shopping places we used to go to before spending all our time online. We’d taken on a new customer that ran a large chain of paint and interior decoration stores. Now, we knew quite a bit about retail—and about the users who sold things at point of sale and managed inventory—but there were some things we didn’t know that were specific to paint and decor stores. For instance, we didn’t know how to sell custom-tinted paint or custom blinds. And we had to learn fast.

为了帮助我们学习，我们请求这三位女士的帮助。他们不是软件人。他们是为需要我们软件的公司工作的室内装饰师。从他们那里，我们了解了销售定制百叶窗的来龙去脉。为了快速学习，我们让他们回想上次销售定制百叶窗的情景。我们要求他们写下他们所做的一切——从客户联系他们的那一刻起，直到百叶窗安装完毕并且客户满意为止。现在这听起来应该很熟悉，因为我们要求他们做与您刚才一样的事情来绘制您的早晨——而且几乎是一样的。他们可以说出他们为销售定制百叶窗所做的工作，就像您可以说出自己的名字一样容易早上做准备。而且，当我们组织他们的任务时，我们都知道没有任何一种方法可以做事，他们每个人做事的方式不同或顺序不同。如果您与一小群不同的人一起尝试早上起床地图，您会看到同样的事情。

To help us learn, we asked for the help of these three ladies. They’re not software people. They’re interior decorators working for the company that wanted our software. From them we learned the ins and outs of selling custom blinds. So that we could learn quickly, we asked them to think back to the last time they sold custom blinds. We asked them to write down everything they did—from the moment a customer contacted them, until the moment the blinds were installed and their customer was happy. Now that should sound familiar, because we asked them to do the same thing you just did to map your morning—and it went pretty much the same way. They could name what they did to sell custom blinds as easily as you could name what you did to get ready in the morning. And, when we organized their tasks, we all learned that there wasn’t any one way to do things, that they each did things differently or in a different order. You’ll see the same thing if you try the getting-up-in-the-morning map with a small group of different people.

从这个简单的讲故事和绘图活动中，我们都对他们现在的工作方式建立了共同的理解。正是从这里开始，我们可以开始将这张地图转化为他们需要在我们以后创建的软件中做的事情。

From this simple storytelling and mapping activity, we all built shared understanding of how they worked now. It was from here that we could begin to translate this map into the things they’d need to do in the software we’d create later.

我不会骗你的。如果您是一名软件专家，您可能需要一段时间才能停止谈论功能和屏幕，并开始编写简短的动词短语来说明人们真正想做的事情。保持练习。你会明白的。

I won’t lie to you. If you’re a software professional, it may take you a while to stop talking about features and screens, and to start writing short verb phrases that say what people are really trying to do. Keep practicing. You’ll get it.

如果您不确切地知道您的用户是谁、她想要完成什么或她如何去做，这将非常困难。可悲的是，在这种情况下尝试构建地图只会指出您不知道的内容。如果那是你所在的地方，那么你将需要更多地了解人们以及他们所做的事情。更好的是，直接与他们合作创建地图。

This will be really hard if you don’t know exactly who your user is, what she’s trying to accomplish, or how she goes about it. Sadly, trying to build a map in this situation will just point out what you don’t know. If that’s where you are, then you’ll need to learn more about people and what they do. Better yet, work with them directly to create a map.

绘制地图可以帮助您看到全局，只见树木不见森林。这是故事地图的最大好处之一。但是，如果您是负责建造森林的人，则需要一次建造一棵树。您已经了解了让故事发挥作用的两个最重要的因素：

Building a map helps you see the big picture, to see the forest for the trees. That’s one of the biggest benefits of story mapping. But if you’re the one responsible for building the forest, you’ll need to do it one tree at a time. You’ve already learned the two most important things that make stories work:

记住这些事情，随着你的前进，一切都会水到渠成。

Keep these things in mind, and everything will fall into place as you go forward.

现在是我们讨论“逐树”使用故事的一些策略的时候了，因为很多地方都可能出错，而且要很好地使用故事，您还需要了解一些其他事项。

It’s time we talked about some of the tactics for using stories “tree by tree,” because a lot can go wrong, and there are a few more things you need to know to use stories well.

SAP 的用户故事映射——一切都与扩展有关

安德烈·施米登

Andrea Schmieden

当 Jeff 首次提出他的用户故事映射概念时，SAP 的我们立即明白了这一点。这似乎是一种简单而有效的方法，可以将产品愿景转化为积压工作，并了解我们要开发什么、为谁开发以及为什么开发。所以我们决定试一试。

When Jeff first presented his concept of user story mapping, it immediately made sense to us at SAP. It seemed to be a simple yet powerful method to turn a product vision into a backlog, and understand what we were going to develop, for whom, and why. So we decided to give it a try.

然而，正如我们很快就会发现的那样，对于一个单独的企业家或单个 Scrum 团队来说可能是一件简单的事情，但对于由多个Scrum 团队组成的产品开发团队来说却是完全不同的野兽。在 SAP，拥有约 20,000 名开发人员的大型开发组织，依赖其他团队的大型产品开发团队通常是常态，而不是例外。我们需要想出一种可靠的方法来为大型组织扩展用户故事映射。

Yet, as we soon were to discover, what might be a simple thing for a lone entrepreneur or an individual Scrum team is a completely different beast for product development teams consisting of several Scrum teams. At SAP, with its large development organization of about 20,000 developers, large product development teams with dependencies on other teams are generally the norm, not the exception. We needed to come up with a reliable way to scale user story mapping for a large organization.

挑战

The Challenge

因此，我们面临的挑战是双重的：

So, the challenge for us was two-fold:

• 我们如何才能映射复杂的产品而不迷失在即时贴中？
• How can we map complex products without getting lost in stickies?
• 如何在开发组织内普及，让人用得上？
• How can we popularize the method within the development organization and enable people to use it?

1.大型产品的用户故事映射

1. User Story Mapping for Large Products

为了找到第一个问题的答案，我们决定最好举办一些实际项目的试点讲习班。我们从一个由热情的教练组成的小团队和大约 10 个试点项目开始，其中最大的一个由 14（！） 个 Scrum 团队组成。在这个试点阶段，我们在研讨会形式、内容、项目阶段、地图格式等几个方面改变了方法。经过几轮反馈和迭代后，我们得出了一组良好实践，这些实践目前看来在我们的大规模开发环境中运行良好。

To find answers to the first question, we decided it was best to run a few pilot workshops with actual projects. We started out with a small team of enthusiastic coaches and approximately 10 pilot projects, the largest consisting of 14(!) Scrum teams. In this pilot phase, we varied the method in several aspects, such as workshop formats, contents, project phases, map formats, and more. After several feedback rounds and iterations, we arrived at a set of good practices that for now seem to work pretty well in our large-scale development context.

关键良好实践

Key Good Practices

当团队首次使用用户故事映射时，我们建议有经验的教练参与。教练安排与请求者的会议并讨论研讨会目标、邀请谁、议程、相关输入等。通常，我们会与整个团队一起举办为期一天的便利研讨会，并根据需要举办小型后续会议。

When a team first uses user story mapping, we recommend the involvement of an experienced coach. The coach sets up a meeting with the requestor and discusses the workshop goals, whom to invite, agenda, relevant inputs, and so forth. Typically, we do a facilitated one-day workshop with the whole team and smaller follow-up sessions as required.

在研讨会当天，我们通常从产品愿景练习开始，例如著名的电梯推介或封面故事^{[ 8 ]}格式，团队在其中描述他们希望在贸易期刊文章中阅读有关其产品的内容一年后。这表明团队是否对大方向有共同的理解，或者他们是否可能需要投资一些额外的研究（例如，额外的访谈、原型测试等）。

On the day of the workshop, we typically start with a product vision exercise such as the well-known Elevator Pitch or the Cover Story^[8] format where the team describes what they would like to read about their product in a trade journal article a year from now. This shows whether the team has a common understanding about the general direction, or whether they might need to invest in some additional research (e.g., additional interviews, prototype testing, etc.).

下一步是查看产品的典型用户。如果研讨会的目标是指定详细的积压工作，则用户角色或角色应该来自用户研究阶段。如果项目处于早期阶段，团队会写下他们的假设。然后可以在用户研究阶段对这些进行测试。事实证明，这是准备用户研究的好方法。这也是设计思维实践和用户故事映射可以很好地协同工作的一个方面。

The next step is to look at the typical users of the product. If the workshop goal is to specify a detailed backlog, the user roles or personas should result from the user research phase. If the project is in an early phase, the team writes down their assumptions. These can then be tested in user research phases. This has proven to be a good way to prepare the user research. This is also an aspect where design thinking practices and user story mapping work very well together.

接下来，我们使用三层方法来定义用户故事：(1) 开始通过高级使用步骤，这些被分解为 (2) 每个用户角色更精细的活动，这些活动又被分解为 (3) 具体的用户故事，格式为“作为 <role>，我想要 <functionality>，所以那个<值>。” 这些用户故事加起来就是第一个产品待办事项列表。这种三层方法对于较大的项目特别有用。在每一层上，团队可以决定在哪些地方深入了解细节是有意义的，以及在哪些地方需要考虑对其他团队的依赖性。这种方法有助于专注于手头的关键开发任务，同时牢记大局。

We next use a three-tier approach to defining user stories: (1) starting with high-level usage steps, these are broken down into (2) finer activities per user role, which in turn are broken down into (3) concrete user stories in the format “as <role>, I want <functionality>, so that <value>.” These user stories add up to a first product backlog. This three-tier approach is especially useful for bigger projects. On each tier, the team can decide where it makes sense to drill down into the details and where dependencies to other teams need to be considered. This approach helps focus on the key development tasks at hand while keeping the big picture in mind.

为了使地图更容易掌握，我们使用颜色编码的便利贴来表示与个人角色或角色相关的活动和用户故事，如下图所示。

To make the map easier to grasp, we use color-coded stickies for activities and user stories related to an individual persona or role, as you can see in the following graphic.

通常，当团队创建地图时，会出现其他方面，例如团队需要做更多研究的“白点”，或未解决的问题、依赖关系或差距。为了强调这些问题，我们使用了不同颜色或不同尺寸的便签纸。乍一看，将所有这些悬而未决的问题都放在地图上似乎很尴尬。然而，根据我们的经验，这是映射过程中最有用的方面之一：您对需要进一步澄清的事情有一个真实而切实的印象。问题摆在桌面上之后，解决起来就容易多了。

Often, while the team is creating the map, additional aspects come up, such as “white spots” where the team needs to do more research, or open questions, dependencies, or gaps. To highlight these issues, we use stickies in different colors or different sizes. At first it might seem awkward to put all these open issues on the map. However, in our experience, this is one of the most useful aspects of the mapping process: you get an honest and tangible impression of the things that need further clarification. After the issues are on the table, it’s a lot easier to tackle them.

当团队达到合理的详细程度时，我们会优先考虑待办事项列表中的用户故事。根据项目的规模和项目阶段，这有时甚至在活动级别而不是用户故事级别完成。我们通常使用简单的投票技术，例如点投票。有时，我们使用简化的 Kano 模型进行投票，这意味着团队将用户故事标记为“必须拥有”、“令人愉悦”或“令人满意”。这些简单的投票结果再次成为与利益相关者、最终用户和客户进一步协调和验证的良好基础。

When the team has reached a reasonable level of detail, we prioritize the user stories in the backlog. Depending on the size of the project and the project phase, this is sometimes done even on the activities level rather than the user stories level. We typically use simple voting techniques, such as dot voting. Sometimes, we use a simplified Kano model for the voting, which means that the teams tag user stories as “Must haves,” “Delighters,” or “Satisfiers.” These simple voting results are again a good basis for further alignment and validation with stakeholders, end users, and customers.

正如我们的一位产品负责人所说，“作为产品负责人，您经常面临将大量需求纳入非常紧迫的时间表的挑战。我们邀请客户参加为期一天的用户故事映射研讨会，事实证明这是一种非常有效的方式，可以就他们的优先事项达成共识。”

As one of our product owners put it, “As a product owner, you often have the challenge to fit lots of requirements into a very tight timeline. We invited our customers to a one-day user story mapping workshop, and it proved to be a very efficient and effective way to get to a common understanding of their priorities.”

更多的细节、详细的工作量估算等通常不是研讨会的一部分，而是在之后以较小的小组进行讨论。

Further details, detailed effort estimations, and so forth are usually not part of the workshop, but rather are discussed in smaller groups afterward.

2. 扩展用户故事映射

2. Scaling User Story Mapping

为了扩展和推广这种方法，最初的教练团队提供了一些材料，例如基于 Excel 的地图模板、角色模板、标准研讨会议程、维基文章和方法描述“备忘单”。此外，正在开发用于用户故事映射的内部工具。

To scale and roll out this approach, the initial team of coaches provided materials such as an Excel-based template for maps, templates for personas, a standard workshop agenda, wiki articles, and method description “cheat sheets.” In addition, an internal tool for user story mapping is being developed.

但是，材料是一回事，办车间又是另一回事。因此，我们再次强烈建议让经验丰富的教练参与这个过程。为了能够提供足够的教练，最初的教练团队培养了更多的教练。这些“初级教练”与高级教练一起参加了一个研讨会，促进了个别会议，然后自己举办了研讨会。我们还在 SAP 全球主要开发地点举办了研讨会和“培训培训师”课程。为了确保我们相互学习，并从各种经验中学习，我们实施了一个全球网络电话会议，教练们可以在其中分享问题和良好实践，并由维基页面和实践社区提供支持。最后但同样重要的是，我们从与 Jeff 的多次精彩交流中学到了很多东西。

However, materials are one thing, and running a workshop is another. So, again, we strongly recommend involving an experienced coach in the process. To be able to provide enough coaches, the initial coaching team trained more coaches. These “junior coaches” attended a workshop with a senior coach, facilitated individual sessions, and then ran workshops on their own. We also ran workshops and “train the trainer” sessions in SAP’s main development locations worldwide. To make sure we learn from one another, and from the various experiences, we implemented a global network call where coaches can share questions and good practices backed up by wiki pages and communities of practice. And, last but not least, we learned a lot from numerous great exchanges with Jeff.

我们在扩展用户故事映射方面的努力取得了成功。我们在不同的单位和地点举办了 200 多个便利的研讨会，现在大多数团队都能够自己成功地使用用户故事映射。

Our efforts at scaling user story mapping were successful. We ran more than 200 facilitated workshops in various units and locations, and now most teams are able to use user story mapping successfully on their own.

故事的想法起源于一个名叫肯特贝克的非常聪明的人。上世纪 90 年代后期，Kent 与其他人一起从事软件开发，他注意到软件开发中最大的问题之一源于使用文档来精确描述我们想要的东西（即需求）的传统过程方法。现在你知道问题所在了。不同的人可以阅读同一份文件并想象不同的事物。他们甚至可以在文档上“签字”，相信他们已经达成一致。

The idea of stories originated with a very smart guy by the name of Kent Beck. Kent was working with other people on software development in the late ’90s, and he noticed that one of the biggest problems in software development sprang from the traditional process approach of using documents to describe precisely what we want—that is, the requirements. By now you know the problem with that. Different people can read the same document and imagine different things. They can even “sign off” on the document believing they’re in agreement.

后来，当我们深入开发软件时——甚至比这更晚，在软件交付之后——我们才意识到我们在考虑不同的事情。许多人将这种缺乏共同理解的情况称为“糟糕的需求”。

It’s later, when we get into the thick of developing software—or even later than that, after it’s delivered—that we realize we weren’t thinking of the same things. Lots of people call this lack of shared understanding “bad requirements.”

让我在这里发泄一下。我很高兴与许多团队合作。我们经常通过谈论他们面临的最大挑战来开始合作。而且，毫无疑问，我听到最多的是“糟糕的要求”。然后每个人都指着那个文件。文档编写者感觉很糟糕——好像他应该多写或少写，或者使用一些很酷的需求技术。那些签字的人先是难过，然后是义愤填膺。“你肯定没想到我会阅读每一个细节！毕竟，我们已经讨论了好几天了。我只是希望你能理解我说的话。反正我也看不懂你那愚蠢的需求文档。” 构建软件的人感到措手不及。他们糊里糊涂地浏览了那些神秘的文件，但他们构建的东西仍然是错误的。每个人最终都讨厌这份文件。

Let me vent a minute here. I have the pleasure of working with lots of teams. And we often start work together by talking about their biggest challenges. And, hands down, the one I hear most is “bad requirements.” And then everyone points at that document. The document writer feels bad—as if he should have written more, or less, or used some cool requirements technique. Those who signed off feel bad at first, and then indignant. “Surely you didn’t expect I’d read every detail! After all, we talked about this for days. I just expected you’d understood what I said. I can’t understand your silly requirements document anyway.” And the people building the software feel blindsided. They muddled their way through those cryptic documents and what they built was still wrong. Everyone hates the document in the end. Yet we still keep trying to write a better one.

但误解文档只是问题的一半。我们浪费了大量的时间和金钱来构建文档描述的内容，后来才发现真正解决预期问题的方法是非常不同的。你没听错。这些文件往往准确地描述了错误的事情。文档通常会描述我们需要什么，但不会描述我们为什么需要它。如果构建软件的人可以简单地与了解将使用该软件的用户以及他们为什么使用它的人交谈，通常会有一种更具成本效益的方式来取悦这些用户。不说话，我们就永远不知道它。

But misunderstanding the document is only half the problem. We waste lots of time and money building what the document describes, only to find out later that what actually solves the intended problem is something very different. You heard me right. Those documents often accurately describe the wrong thing. Documents usually describe what we need, but not why we need it. If the person building software could simply speak with someone who understood the users who will be using the software and why they’ll be using it, there’s often a more cost-effective way to delight those users. Without talking, we just never know about it.

肯特的简单想法是阻止它——停止如此努力地编写完美的文档，并聚在一起讲故事。故事的名字不是来自它们应该如何编写，而是来自它们应该如何被使用。让我更加激动地重复一遍。现在你应该停止你正在做的任何事情并大声说出来：

Kent’s simple idea was to stop it—to stop working so hard on writing the perfect document, and to get together to tell stories. Stories get their name not from how they’re supposed to be written, but from how they’re supposed to be used. Let me repeat that with more emotion. Right now you should stop whatever you’re doing and say this out loud:

肯特的想法很简单。如果我们聚在一起讨论我们正在用软件解决的问题，谁会使用它，为什么，那么我们就可以一起找到解决方案，并在此过程中建立共同的理解。

Kent’s idea was simple. If we get together and talk about the problem we’re solving with software, who’ll use it, and why, then together we can arrive at a solution, and build shared understanding along the way.

不久前，我开始注意到整个故事有点偏离方向了；也就是说，许多写书、教学和使用书籍的人都专注于写故事的活动。如果每次有人问我如何写好故事时我都能得到一毛钱，我得到的毛钱会比几章前收集到的还要多。

A while back I began to notice that this entire story thing had gone a bit sideways; that is, lots of the people writing books, teaching, and using them focused on the activity of writing stories. If I had a dime for every time I’ve been asked how to write good stories, I’d have even more dimes than I collected a few chapters ago.

我全神贯注于写故事，然后回到肯特，以确保我没有遗漏任何东西。在电子邮件对话过程中，肯特解释了这个想法的来源：

With all the focus on writing stories, I went back to Kent to make sure I wasn’t missing something here. Over the course of an email conversation, Kent explained where the idea came from:

所以这个想法是有说服力的，如果你在听众的脑海中产生能量、兴趣和愿景，你就知道你做对了。那很大。而且这听起来比阅读典型的需求文档有趣得多。^{[ 9 ]}

So the idea is telling, and you know you’re doing it right if you’re generating energy, interest, and vision in the listener’s mind. That’s big. And it sounds a lot more fun than reading a typical requirements document.^[9]

但是那些开始使用故事进行软件开发的人——以及他们头脑中仍然保留着传统过程模型的人——往往会专注于写作部分。我见过团队用写故事取代他们的传统需求流程，然后在尝试写故事来准确传达应该构建的内容时感到沮丧。如果您现在正在这样做，请停止。

But folks who start using stories for software development—and who still have a traditional process model in their heads—tend to focus on the writing part. I’ve seen teams replace their traditional requirements process with story writing, and then get frustrated trying to write stories to precisely communicate what should be built. If you’re doing that now, stop it.

在《Extreme Programming Installed 》一书中，Ron Jeffries 等人。(Addison-Wesley Longman Publishing) 描述最好的故事过程：

In the book Extreme Programming Installed, Ron Jeffries et al. (Addison-Wesley Longman Publishing) describe the story process best:

如果这听起来很简单，那是因为它确实如此。请记住，简单并不容易。

If it sounds simple, it’s because it is. Just remember, simple isn’t easy.

达成这项协议的途径不仅仅是一张牌和大量的挥手。如果对话包含很多内容，例如简单的人物角色、工作流程图、UI 草图和任何其他有助于解释事情的传统软件模型，那么对话会进行得最好。这样，您不必只是挥手——您也可以指指点点。无论我们将什么带入对话，我们都会进行标记、书写、更正和更改。在那次谈话中，我们甚至会当场创造很多东西。使用白板或活动挂图纸。并且在您离开之前不要忘记拍摄一些“假期照片”。您创建的内容的照片将帮助您回忆起难以写下的对话的所有细节。

The path to get to this agreement isn’t just a single card and lots of hand waving. The conversation goes best if it includes lots of things such as simple personas, workflow diagrams, UI sketches, and any other traditional software model that’ll help explain things. That way, you don’t have to just wave hands—you can point a lot, too. Whatever we bring into the conversation we’ll mark up, write on, correct, and change. We’ll even create a lot of things on the spot during that conversation. Use a whiteboard or flipchart paper. And don’t forget to take some “vacation photos” before you leave. Photos of what you’ve created will help you recall all the details of the conversation that would be difficult to write down.

好的故事对话有很多文字和图片。

Good story conversations have lots of words and pictures.

在谈话中保持你决定的验收标准大而显眼。这个团队使用活动挂图纸边走边记录。

Keep the acceptance criteria you decide on big and visible during the conversation. This team uses flipchart paper to record as they go.

仅此而已。这是肯特颠覆性的简单想法。而且，如果你这样做，我向你保证它会改变一切。

That’s all there is. That’s Kent’s disruptively simple idea. And, if you do it, I promise you it’ll change everything.

除非没有。

Unless it doesn’t.

对于习惯于以老式方式工作的人来说，这种对话可能会非常糟糕。他们又回到了他们带来东西的人的旧模式，努力工作以准确地向对方传达他想要的东西，而另一个人则努力尝试理解并在对方说的话上打孔. 如果这样持续太久，他们往往会有互相戳洞的感觉，不利于事情的完成。

For people used to working the old-fashioned way, this conversation can go really badly. They fall back into their old patterns of the person bringing in stuff, trying to work hard to communicate exactly what he wants to the other person, and the other person working hard to try to understand and then punch holes in what the other person is saying. If this goes on too long, they often feel like punching holes in each other, which is not conducive to getting things done.

有一些事情要记住，以帮助这些对话进行得更好。令人高兴的是，这就是下一章的内容。

There are some things to keep in mind to help these conversations go better. Happily, that’s what the next chapter is about.

这是我的朋友雷切尔戴维斯。她手里拿着一张故事卡。

This is my friend Rachel Davies. And she’s holding a story card.

1990 年代后期，她在一家名为 Connextra 的公司工作。Conntextra 是极限编程的最早采用者之一，极限编程是故事的来源。当 Connextra 的人们开始使用故事时，他们发现他们遇到了一些常见的问题。在 Connextra 撰写故事的大多数人来自销售和市场营销部门。他们倾向于写下他们需要的功能。但是，当开发人员需要进行对话时，他们需要找到最初的利益相关者并开始良好的对话——包括谁和为什么。仅仅知道功能的名称并不能帮助团队找到合适的人与之交谈或开始正确的讨论。而且，那时候，没有太多关于卡片上可以或应该包含什么的指导。Connextra 的模板随着时间的推移而演变。这不是雷切尔特意发明的。相当，

In the late 1990s she worked for a company called Connextra. Conntextra was one of the earliest adopters of Extreme Programming, the Agile process where stories came from. When the Connextra folks started using stories, they found they ran into some common problems. Most of the people who wrote the stories at Connextra were from sales and marketing. They tended to write down the feature they needed. But, when it came time for developers to have conversations, they needed to find that original stakeholder and get a good conversation started—one that included who and why. Just having the name of the feature wasn’t helping the team find the right people to talk to, or to start the right discussions. And, back then, there wasn’t much guidance about what could or should be on a card. The template evolved over time at Connextra. It wasn’t Rachel’s invention specifically. Rather, it was the entire organization’s desire to build things that mattered.

使用该模板一段时间后，Connextra 的人们想炫耀一下他们很酷的新技巧。他们打印了一堆示例卡片，以在 XPDay 2001（伦敦的一个小型会议）上炫耀。这就是雷切尔手里拿着的东西。这是她的最后一张牌，很可能是现存的最后一张牌，所以这使它成为历史文物。

After using the template for a while, the folks at Connextra wanted to show off their cool new trick. They printed a bunch of example cards to show off at XPDay 2001, a small conference in London. That’s what Rachel is holding. It’s her last card, and might very well be the last card in existence, so that makes it a historical artifact.

模板是这样的：

The template goes like this:

Connextra 的人们使用这个简单的模板来编写他们故事的描述。请注意，他们的故事仍然有简短而有用的标题。他们发现，多写一点点来开始讲述故事会迫使他们停下来思考：谁、什么以及为什么。而且，如果他们不知道，他们可能会质疑他们是否应该写这个故事。

The folks at Connextra used this simple template to write the descriptions of their stories. Note that their stories still have short, useful titles. They found that writing this little extra bit to start to tell the story forced them to pause and think about: who, what, and why. And, if they didn’t know, they might question whether they should be writing the story at all.

当他们坐下来讨论故事时，他们会拿起那张卡片，然后阅读描述。这个描述开始了谈话。

When they sat down to have the story conversation, they’d pick up that card and then read that description. That description started the conversation.

如果您在故事地图之外拿起一张单独的卡片，模板是启动对话的好方法。请记住，在第 1 章中，Gary 地图正文中的一张卡片上写着“上传图像”。该卡片是“自定义我的促销传单”卡片下的详细信息之一。我在地图卡片上写的是那些简短的动词短语——用户使用我的软件执行的任务。但是当我自己拿起一个时，我将需要在地图中描述的用户大旅程中间拿起故事。我可能会说：

If you’re picking up an individual card outside of a story map, the template is a good way to boot up the conversation. Remember in Chapter 1 that one of the cards in the body of Gary’s map said, “Upload an image.” And that card was one of the details under the card “Customize my promo flyer.” What I write on the cards in a map are those short verb phrases—the tasks the users are performing with my software. But when I pick one up by itself, I’ll need to pick up the story in the middle of the user’s big journey described in the map. I might say:

这是一个很酷的把戏。我可以找到挂在地图上方的不同用户的卡片，而用户更大的目标往往就在你随时查看的卡片上方的卡片中。

That’s a pretty cool trick. I can find the cards for different users hanging above the map, and the users’ bigger goal is often in the card above the one you’re viewing at any one time.

但请记住——这只是一个话题的开场白。而且，事实上，对话可能会像这样继续：

But remember—it’s just a conversation starter. And, in fact, the conversation might continue like this:

事实上，我和加里的很多谈话都是这样进行的。在我们谈话时，我们会在白板上或卡片上写下一些东西。不久之后，我们就会草拟想法。

In fact, a lot of the conversation I had with Gary went like that. As we were talking, we’d write something down on a whiteboard or on the card itself. Before too long we’d be sketching ideas.

您可以看到非常短的模板不足以成为规范。但是，当我们使用该模板开始对话时，我们最终会进行比仅仅谈论文件上传器更丰富的对话。

You can see that the very short template isn’t nearly enough to be the specification. But when we start a conversation using that template, we end up in a much richer conversation than if we’d just talked about a file uploader.

术语模板僵尸来自Adrenaline Junkies and Template Zombies: Understanding Patterns of Project Behavior一书汤姆德马科等人。（多塞特之家）。这个名字说明了一切，但我会给你作者的定义：

The term template zombies comes from the book Adrenaline Junkies and Template Zombies: Understanding Patterns of Project Behavior by Tom DeMarco et al. (Dorset House). The name says it all, but I’ll give you the authors’ definition:

就像那个模板一样简单，它被滥用了很多。我看到人们真的很难在不合适的时候将想法强加到模板中。有关后端服务或安全问题的故事可能具有挑战性。我看到人们从自己的角度写作和思考事情，而不是最终受益者的角度：“作为产品负责人，我希望你构建一个文件上传器，以满足客户的需求。” 诸如此类的讨厌的事情。

As simple as that template is, it gets abused quite a bit. I see people really struggle to force ideas into the template when they just don’t fit. Stories about backend services or security issues can be challenging. I see people writing and thinking about things from their own perspective, not that of the people who ultimately benefit: “as a product owner, I want you to build a file uploader so that the customer requirements are met.” Nasty things like that.

更糟糕的是，模板已经变得如此普遍，并且被普遍教导，以至于有些人认为如果不是以这种形式编写的，就不是一个故事。许多人甚至不再在故事中使用标题，而是在每张卡片上只写下那句长话。想象一下，尝试阅读以这种方式编写的故事列表。想象一下，尝试使用故事地图向某人讲述一个故事，其中每个便签都是这样写的。这对大脑来说很难。

Even worse, the template has become so ubiquitous, and so commonly taught, that there are those who believe that it’s not a story if it’s not written in that form. Many people have even quit using titles on stories and write only that long sentence on every single card. Imagine trying to read through a list of stories written that way. Imagine trying to tell someone a story using a story map where every sticky is written that way. It’s tough on the brain.

这一切都让我很难过。因为故事的真正价值不在于卡片上写的内容。它来自我们讲故事时学到的东西。

All of this makes me sad. Because the real value of stories isn’t what’s written down on the card. It comes from what we learn when we tell the story.

这张照片中的人正在学习滑雪。^{[ 10 ]}如果你曾经学过滑雪，并且有人在教你，你就会做这个人正在做的事情。它被称为扫雪机。在这里，您可以将滑雪板的尖端放在一起并靠在滑雪板的内侧边缘上。当你的脚上夹着两块滑板时，这是控制速度和保持直立的最简单方法。这是我推荐的学习滑雪的方式。但这不是最佳实践，而是最佳学习实践。没有奥林匹克扫雪机比赛。你酷炫的扫雪机姿势不会给斜坡上的任何人留下深刻印象。不过，这没什么好尴尬的。如果人们看到你那样滑雪，他们就会知道你在学习。

The person in this picture is learning to ski.^[10] If you’ve ever learned to ski, and someone helpful is teaching you, you’ll do what this person is doing. It’s called a snowplow. It’s where you put the tips of your skis together and lean on the inside edges of your skis. It’s the easiest way to control your speed and stay upright when you’ve got two slippery boards clamped to your feet. It’s the way I’d recommend learning to ski. But it’s not best practice—it’s a best learning practice. There’s no Olympic snowplow event. You won’t impress anyone on the slopes with your cool snowplow stance. It’s nothing to be embarrassed of, though. If people see you skiing that way, they’ll know you’re learning.

对我来说，故事模板有点像学习扫雪机。用它来写你的第一个故事的描述。大声说出来开始你的故事对话。但是，如果您发现它并不总是有效，请不要太担心。就像滑雪者的扫雪技术一样，它不是困难地形的最佳选择。

For me, the story template works a bit like learning the snowplow. Use it to write the descriptions of your first stories. Say it aloud to start your story conversations. But don’t get too concerned if you find that it doesn’t always work. Just like the snowplow technique for skiers, it’s not the best choice for difficult terrain.

我最喜欢的模板：如果我在便利贴或卡片上写故事，它们不会放在更大的故事地图中，我先给他们一个简短的标题，然后在标题下面写下：

My favorite template: if I’m writing stories on sticky notes or cards, and they won’t be sitting inside a bigger story map, I’ll first give them a short, simple title, and then under it I’ll write:

而且我会在每行之间给出几行，因为我想具体说出所有不同的人，说一下是什么，并记下不同的原因。当我们开始谈论这些故事时，我想在卡片上留出空间来添加额外的信息。当人们在卡片中间写标题时，这实际上是我的一个小毛病，因为当我们开始谈话时，我没有任何空间做笔记。但我就是那样挑剔。

And I’ll give a couple of lines in between each, because I’ll want to specifically name all the different whos, say a little about the what, and make notes about the different reasons why. I’ll want to leave room on the card to add extra information when we start talking about the stories. It’s actually a pet peeve of mine when people write the title in the middle of the card, because it doesn’t leave me any room to make notes when we start talking. But I’m nitpicky that way.

因为有很多话要谈，而且你不想忘记，所以确保您正在记录特定的事情，以帮助您记住您所做的决定，或者您需要研究的问题和假设。不要忘记将您的想法外化，以便讨论中的其他人可以看到记录的内容。

Because there’s a lot to talk about, and you won’t want to forget it, make sure you’re recording specific things that help you remember the decisions you made, or the questions and assumptions you’ll need to look into. Don’t forget to externalize your thinking so that others in the discussion see what’s recorded.

如果你写下来了，你可以拿起来以后参考。如果它贴在墙上，您只需指向它即可。而且，如果你们作为一个团队一起交谈，您会发现不必如此频繁地重复所有内容，因为人们会记住——尤其是如果您用简单的图画和文件……那些度假照片来固定你们的谈话。

If you write it down, you can pick it up and refer to it later. If it’s posted on the wall, you can just point at it. And, if you’re talking together as a team, you’ll find you won’t have to repeat everything so often, because people will remember—especially if you anchored your conversations with simple drawings and documents…those vacation photos.

这个小组正在进行故事讨论。在他们交谈时，他们将自己的想法形象化，并对他们的决定做笔记。

This small group is having a story discussion. As they talk, they visualize their ideas and make notes about what they decide.

我最喜欢的方法是做他们正在做的事情。我们谈话时，我会在活动挂图纸或白板上记录下来。我喜欢直接在黑板上记下谁在对话中，然后在完成后给黑板拍照。我将使用 wiki 或其他工具共享照片。我知道我可以在以后需要时提取细节或更正式地写下它们。如果我不记得确切说了什么，谈话中的其中一个人可能会记得。幸好我把他们的名字写下来了。

My favorite approach is to do exactly what they’re doing. I record on flipchart paper or a whiteboard as we talk. I like making a note of who was in the conversation directly on the board, and then photographing the board when I’m done. I’ll share the photo using a wiki or other tool. I know I can extract details or write them up more formally when I need them later. If I can’t remember exactly what was said, one of those people in the conversation might. It’s a good thing I wrote their names down.

想想你可以在故事中谈论多少内容是令人生畏的。在这一点上，您可能想回到过去的美好时光，那时您需要做的就是担心理解“需求”。回到真正解决问题不是您的工作的时候。回到你只需要构建你被告知的东西的时候，确保它是正确构建的东西是别人的问题。但我相信你和大多数人都非常喜欢解决问题。所以现在是你的机会。

It’s daunting to think about how much there is you could be talking about in stories. At this point, you may want to go back to the good old days when all you needed to do was worry about understanding the “requirements.” Back when it wasn’t your job to really solve problems. Back when you just needed to build what you were told to, and it was someone else’s problem to make sure it was the right thing to build. But I believe that you, and most people out there, really like solving problems. So now’s your chance.

您可能已经想到，要谈论所有这些事情，就会有很多信息需要跟踪。所有这些东西都放不下便签纸或索引卡。你是对的。它不会。那么让我们接下来谈谈这张卡上真正发生了什么，什么没有发生。

It may have occurred to you that with all these things to talk about, there will be a lot of information to keep track of. And all that stuff isn’t going to fit on a sticky note or an index card. You’re right. It won’t. So let’s talk next about what really does go on that card, and what doesn’t.

如果我是产品经理或产品负责人，并且我对这款产品的成功负有责任，那么我必须对我的目标市场有更多的了解。我需要假设有多少人会购买或使用该产品，或者它将如何影响我公司的盈利能力。我想谈谈那些事情。

If I’m a product manager or product owner, and I’m responsible for the success of this product, then I have to know a little more about my target market. I need to form some hypothesis about how many people will buy or use this product, or how it’s going to affect the profitability of my company. I’ll want to talk about those things.

如果我是一名业务分析师，我可能会深入研究很多细节，所以我需要了解用户界面中正在发生的事情，以及用户界面背后的系统中的业务规则。

If I’m a business analyst, I might be diving into a lot of details, so I need to understand what’s going on in the user interface, and the business rules in the system that are behind the user interface.

如果我是一名测试人员，我需要考虑软件可能在哪些方面出现故障。我需要进行一些对话来帮助我制定一个好的测试计划。

If I’m a tester, I need to think about where the software is likely to fail. I need to have some conversations to help me put together a good test plan.

如果我是一名 UI 设计师，我不想被告知 UI 是什么样子，就像开发人员不想被告知代码应该如何编写一样。我想知道谁在使用它，为什么以及他们在做什么，这样我就可以设计一个有用且可用的用户界面。

If I’m a UI designer, I don’t want to be told what the UI looks like any more than a developer wants to be told the way the code should be written. I’ll want to know who’s using it, and why and what they’re doing, so I can design a useful and usable user interface.

最后，如果我是负责协调这群人的项目经理，我将不得不注意他们在讨论所有这些细节时做出决定。当它开始时，我需要注意依赖关系、时间表和开发状态。

Finally, if I’m a project manager responsible for coordinating this group of people, I’ll have to pay attention when all of them are talking to make decisions about all these details. I’ll need to pay attention to dependencies, schedules, and the status of development when it gets started.

这是很多对话。其中一些必须先于其他发生。而且其中许多发生不止一次。因此，为了使其准确，我们可能必须在 3个C中再添加十几个C。但令人高兴的是，如果你们真的在一路上进行对话并建立共同的理解，你就会避免很多误解和路线更正。

That’s a lot of conversations. And some of them have to happen before others. And many of them happen more than once. So, to make it accurate, we’d probably have to add another dozen C s to the 3 C s. But happily, if you’re really having conversations and building shared understanding along the way, you’ll avoid lots of misunderstandings and course corrections.

当你说出那个标题中的词时，我希望你会想起老电影《大白鲨》，在第一次近距离亲眼看到这条巨大的鲨鱼后，警察局长布罗迪对昆特说：“你需要一艘更大的船。”

When you say the words in that heading, I hope you’re thinking of the old movie Jaws when, after seeing the huge shark up close and personal for the first time, Police Chief Brody says to Quint, “You’re gonna need a bigger boat.”

你看，最初的想法也是，我可以拿起一张卡片，在正面写上标题，然后当我们交谈时，我可以把它翻到背面，写下我们同意的所有事情的细节上来了。我可以画出用户界面的草图，并在卡片上写下很多其他信息。在某些项目上，它确实可以这样工作。可以的话很酷，这通常是小团队紧密合作并拥有大量隐性知识的副作用。这些是不需要写太多就可以记住的团队。

You see, the original idea was also that I could pick up a card and write the title on the front, and then as we had conversations, I could flip it over on the back and write the details of all the things we agreed to that came up. I could sketch the user interface and write a lot of other information on the card. On some projects, it can really work this way. It’s cool when it can, and it’s usually a side effect of small teams working closely together with a lot of tacit knowledge. Those are the teams that don’t have to write much to remember.

但我认为即使是 Kent 和那些完善故事概念的人实际上也没有想到所有这些不同的人之间的所有这些对话都可以包含在一张卡片上，事实上，他们通常不会。

But I don’t think even Kent and the folks who perfected the concept of stories actually thought that all these conversations between all these different people could be contained on just a single card, and in fact, they usually aren’t.

对我有用的比喻是图书馆卡片目录中的一张卡片，对于年龄足够大的人来说，图书馆实际上有卡片目录。写在卡片上的故事有点像那些。

The metaphor that works for me is a card in a library card catalog, for people who are old enough to remember when libraries actually had card catalogs. Stories written on cards work a bit like those.

如果我从卡片目录中挑选一张卡片，它会提供足够的信息让我识别这本书。它可能有标题、作者姓名、描述、书的页数、书的类别（例如“非小说类”）和代码（还记得杜威先生的小数点吗？）到我可以实际找到的位置图书馆里的那本书的副本。该卡只是一个易于查找和整理的标记。没有人会将卡片与一本书混淆。卡片目录很方便，因为它比成千上万本书占用的空间要少得多。我可以用不同的方式组织卡片——例如，按作者或按主题。

If I pick up a card from a card catalog, it’s going to have just enough information for me to identify the book. It likely has a title, the author name, a description, the page count of the book, the category of the book—like “nonfiction”—and a code (remember Mr. Dewey’s decimals?) to a location where I can actually find a copy of the book in the library. The card’s just a token that’s easy to find and organize. No one confuses the cards with a book. The card catalog is handy because it takes a lot less space than thousands of books would. And I can organize cards in different ways—by author, for example, or by subject.

您的故事将以同样的方式运作；也就是说，您可以将它们写在卡片上，将它们保存在电子表格的列表中，将它们输入到您最喜欢的跟踪工具中，或者将它们输入到您公司让您使用的跟踪工具中——您知道，每个人都在抱怨这个工具。在图书馆里，您知道某处有一本书，如果您在卡片目录中找到了正确的卡片，就很容易找到它。同样，对于一个故事，您知道某处的信息量越来越多。它随着每次对话而成长和发展。而且，希望无论您的公司选择如何跟踪这些信息，它也很容易找到。

Your stories will work the same way; that is, you may write them on cards, keep them in a list in a spreadsheet, enter them into your favorite tracking tool, or enter them in the tracking tool your company makes you use—you know, the one everyone grumbles about. In a library, you know there’s a book out there somewhere, and if you have identified the right card filed away in the card catalog, it’s easy to find it. Similarly, with a story, you know there’s a growing amount of information out there somewhere. It grows and evolves with each conversation. And, hopefully, however your company chooses to keep track of the information, it’s easy to find, too.

如果你想去真正的老派，请保留细节所有这些讨论都贴在墙上的大张挂图纸上，这样你就可以随时谈论它们。但请记住：当你完成工作时，你会想把它们拿下来，否则你会用完墙上的空间。你会想要给它们拍照，并将这些照片保存在某个地方以供子孙后代使用。

If you want to go really old school, keep the details of all those discussions taped onto big sheets of flipchart paper on the wall so you can keep talking about them whenever you want. But remember: you’ll want to take them down when you’ve completed the work or else you’ll run out of wall space. And you’ll want to photograph them and keep those photos somewhere for posterity.

工具创造者如何讨论好故事

这是我的朋友 Sherif，他是一家名为 Atlassian 的公司的产品经理。Atlassian 制作了 Confluence，这是一个流行的 wiki，用于各种组织，以跟踪这些组织积累的知识等。他们还使 JIRA 成为敏捷开发中更流行的管理工作的工具之一。您可能会认为一家专注于构建用于以电子方式保存和共享信息的工具的公司会使用自己的工具——可以这么说——“吃他们自己的狗粮”——你会说 Atlassian 是对的。但它也知道如何进行良好的面对面对话。

This is my friend Sherif, who’s a product manager at a company called Atlassian. Atlassian makes Confluence, a popular wiki used in a huge variety of organizations to keep track of the knowledge those organizations accumulate, among other things. They also make JIRA, one of the more popular tools for managing work in Agile development. You’d think a company that focuses on building tools used for keeping and sharing information electronically would use its own tools— “eat their own dog food,” so to speak—and you’d be right that Atlassian does. But it also understands how to have good face-to-face conversations.

当我在悉尼的 Atlassian 办公室走动时，我看到墙上贴满了便利贴、白板图和屏幕线框。如果仔细观察，您会发现便签参考了团队所依赖的那些工具中的票号。它们灵活地在工具和物理空间之间来回移动。当 Sherif 向我展示他们在 Confluence 中保存的内容时，我对照片、短视频和来回讨论的组合感到惊讶。

When I walk around the Atlassian office in Sydney, I see the walls covered with sticky notes, whiteboard drawings, and screen wireframes. If you look closely, you’ll see that the sticky notes reference ticket numbers in those tools the team relies on. They nimbly move back and forth from tools to physical space. When Sherif shows me what they keep in Confluence, I’m amazed at the combination of photographs, short videos, and back-and-forth discussions.

在他的《敏捷软件开发：合作博弈》（Addison-Wesley Professional）一书中，Alistair Cockburn 创造了术语信息辐射器来描述墙上有多大的可见信息将有用的东西辐射到房间里。路过的人看着它并与之互动。当信息活跃且有用时，许多对话最终会出现在墙上，人们可以指向并添加到那里积累的信息中。

In his book Agile Software Development: The Cooperative Game (Addison-Wesley Professional), Alistair Cockburn coined the term information radiator to describe how big, visible information on the wall radiates useful stuff into the room. People walking by look at it and engage with it. When the information is alive and useful, lots of conversations end up at the wall, where people can point to and add to the information accumulating there.

当我走进墙壁干净，甚至覆盖着令人愉悦的艺术品——或者最糟糕的是，励志海报——的环境时，我会感到难过。这些有用的墙壁每天都可能发生如此多的伟大合作。如果墙上的东西是一个信息辐射器，有些人将人们使用的工具称为信息冰箱——因为这是保存信息的地方——并且可能会被一层薄薄的冰覆盖，就像你的后背的东西一样冰箱。（我总是对我在那里的发现感到震惊。）

When I walk into environments where the walls are clear, or even covered with pleasant artwork—or worst of all, motivational posters—it makes me sad. There’s so much great collaboration that could be happening every day with those useful walls. If what’s on the wall is an information radiator, some refer to the tools people use as an information icebox—because that’s where information goes to be preserved—and potentially be crusted over with that thin layer of ice like that stuff in the back of your freezer. (I’m always shocked by what I find back there.)

这就是 Atlassian 对我来说真正了不起的地方。他们使信息保持活力和有用，无论是在他们使用的工具中还是在他们使用的工具之外。

That’s what’s really remarkable to me about Atlassian. They keep information alive and useful, both in and out of the tools they use.

故事卡上到底有什么？

想象一下图书馆卡片目录中的一张卡片。那张卡片上有有用的信息，可以帮助您组织它并确认您在谈论正确的书。一张好的故事卡有点像那样。

Imagine a card from a library’s card catalog. That card’s got useful information on it to help you organize it and confirm you’re talking about the right book. A good story card is a bit like that.

您希望在卡片上找到的常见内容是：

Common things you’d expect to find on a card are:

简称

Short title

当您谈论它时，很容易将其插入对话中。一个好的标题是您故事中最有价值的部分。如果它让人感到困惑，不要害怕重写它。

One that’s easy to insert into a conversation when you’re talking about it. A good title is the most valuable part of your story. Don’t be afraid to rewrite it if it’s confusing people.

描述

Description

一两句话描述了我们的想象。最好描述谁、什么和为什么——谁使用或需要它，他们将用它做什么，以及他们希望从中获得什么好处。

A sentence or two that describes what we’re imagining. It’s a good idea to describe who, what, and why—who uses or needs it, what they’ll do with it, and what benefit they hope to get from it.

当您开始讨论故事时，您将添加总结您的一些讨论的信息。这将包括以下内容：

As you begin to discuss stories, you’ll add information that summarizes some of your discussions. That’ll include stuff like:

故事编号

Story number

当你得到一堆这些或将它们放入跟踪系统时，这将帮助您找到它们——有点像图书馆中的杜威十进制系统。但是，无论您做什么，请不要开始通过编号来引用您的故事。如果这样做，则表明您没有选择一个很好的标题。甚至图书管理员也不会通过杜威十进制数字来引用书籍。

When you get a bunch of these or put them into a tracking system, this will help you find them—sort of like the Dewey Decimal System in a library. But, whatever you do, please don’t start referring to your stories by their number. If you do, it’s a sure signal you haven’t chosen a very good title. And even librarians don’t refer to books by their Dewey Decimal numbers.

估算、规模或预算

Estimate, size, or budget

当您开始讨论这个故事时，您需要预测构建该软件可能需要多长时间。这有很多术语，例如estimate、size或budget。使用贵公司使用的术语。

As you begin to discuss the story, you’ll want a prediction on how long it might take to build the software. There are lots of terms for this, like estimate, size, or budget. Use the term your company uses.

价值

Value

您可能会就一件事相对于另一件事的相对价值进行冗长的讨论。有些人可能会使用数字刻度。有些人可能会用high、medium或low来注释卡片。

You might have lengthy discussions about the relative value of one thing over another. Some might use a numeric scale. Some might annotate cards with high, medium, or low.

指标

Metrics

如果您真的关心结果，请确定您将在软件发布后跟踪的具体指标，以确定软件是否成功。

If you really care about results, identify specific metrics you’ll track after the software is released to determine whether the software was successful.

依赖关系

Dependencies

其他故事这个可能取决于或一起去。

Other stories that this one might depend on or go with.

地位

Status

是否计划用于特定版本？开始了吗？进行中？完毕？

Is it planned for a particular release? Is it started? In progress? Done?

日期

Dates

就像一本书的卡片上有它的出版日期一样，您可以保留这个故事的添加、开始和结束日期。

Just as a book’s card has the date it was published, you might keep the date this story was added, started, and finished.

你可以在卡片上随便写下你喜欢的任何其他笔记。或者将其翻到背面并写下注释或带项目符号的验收标准。

You could scribble any other notes you like on the card. Or flip it to the back and write notes or bulleted acceptance criteria.

您的卡上唯一需要的是一个好的标题。所有这些其他信息可能会有帮助，但您和您的团队可以决定要使用哪些信息。

The only thing that’s required on your card is a good title. All those other bits of information could be helpful, but you and your team get to decide which you’d like to use.

不太适合卡片，这很好。请记住，它只是您用来计划的一个标志。您也可以使用卡片或便利贴。有了实物卡片，您可以在对话中指着墙上或桌面上的卡片时使用这样那样的方便词。你不能用厚文件做到这一点。有了卡片，你可以在桌子周围洗牌，按重要性排列，把它们贴在墙上，然后在你说话的时候四处挥动它们来强调你的观点。如果你对厚文件这样做，你可能会伤害到别人——也许是你自己。当然，您会希望将成堆的卡片排列成故事地图，以讲述更大的故事。

Not too much fits on the card, and that’s good. Remember, it’s just a token you’ll use to plan with. You could use cards, or sticky notes, too. Having the physical cards lets you use handy words like this and that in conversations as you point to cards on a wall or tabletop. You can’t do that with a thick document. With cards, you can shuffle them around a desk, rank them by importance, tape them to the wall, and wave them around while you’re talking to make your point more emphatically. If you were doing that with a thick document, you could hurt someone—perhaps yourself. And, of course, you’ll want to arrange bunches of cards into story maps to tell even bigger stories.

伐木工人在森林里遇到了一个人。这个人正在努力工作，试图通过用锤子敲打来砍倒一棵树。伐木工人拦住男人说：“嘿，你用错工具了！试试这个……”然后递给那个人一把锯。男人向他道谢，伐木工人继续赶路，他很高兴知道自己帮了忙。然后这个人开始用锯子敲树，就像他用锤子一样。

A lumberjack comes across a man in the forest. The man is working hard trying to chop down a tree by hitting it with a hammer. The lumberjack stops the man and says, “Hey, you’re using the wrong tool! Try this…” and hands the man a saw. The man thanks him, and the lumberjack continues on his way, happily knowing that he’s helped. The man then begins striking the tree with the saw the same way he was with the hammer.

这个笑话提醒我，我们可以用错工具，也可以用错工具。

This joke reminds me that we can use the wrong tool for the job, and we can also use the tool wrong.

当我告诉人们像 Atlassian 这样的公司如何使用工具时，他们通常会感到惊讶。他们常常感到惊讶，因为他们一直在尝试使用工具来替代白板和便利贴。而且，可以预见的是，他们一直在努力解决这个问题。可能是他们为错误的工作使用了错误的工具，或者错误地使用了正确的工具。要弄清楚可能出了什么问题，最好先查看作业，而不是工具。

When I tell people how companies like Atlassian use tools, they’re usually surprised. They’re often surprised because they’ve been trying to use tools as a replacement for whiteboards and sticky notes. And, predictably, they’ve been struggling with that. It may be that they’re using the wrong tool for the wrong job, or using the right tool wrong. To figure out what might be going wrong, it’s best to look at the job first, and not the tool.

建立共识

Building Shared Understanding

当我们共同讲述故事并就要构建的解决方案做出决策时，我们的首要目标是建立共同的理解。这就是外化和组织您的想法至关重要的地方。没有什么比在白板前用便利贴进行面对面的工作更好的了。但是，如果您必须与远程工作的其他人一起完成这项任务，那就很难了。让您看到彼此面孔的视频会议工具并没有太大帮助，因为您需要看到的不是他们的面孔，而是您将要放在墙上或桌面上的想法。

When we’re working together to tell stories and make decisions about solutions to build, our first goal is to build shared understanding. This is where externalizing and organizing your thoughts is critical. And nothing beats face-to-face work in front of a whiteboard, armed with sticky notes. But, if you’ve got to accomplish this task with others working remotely, this is tough. Video conference tools that let you see one another’s faces don’t help much, since it’s not their faces you need to see—it’s the ideas you’ll be placing on the wall or tabletop.

在视频会议期间使用文件摄像机或网络摄像机，让远程人员可以看到墙上正在创建的内容。

Use a document camera or web camera during a video conference to let remote people see what’s being created on the wall.

我曾与在视频会议两端都有摄像机的团队合作过，通话的重点是墙上不断增长的模型，而不是团队成员的脸。

I’ve worked with teams that have video cameras at both ends of a video conference, and the call focuses on the growing models on the wall, not the team members’ faces.

如果你使用一种工具来可视化，那么理想的情况是对话双方的人都可以添加和移动东西，就像他们在白板上一起工作一样。这是来自名为 Cardboard 的工具的屏幕。

If you use a tool to visualize, it’s ideal if people on both sides of the conversation can add and move things around, just like they could if they were working together at a whiteboard. This is a screen from a tool called Cardboard.

使用 Cardboard 的人正在创建地图，而 Cardboard 的创建者之一 David Hussman 在墙上绘制地图。从其他位置共享同一张地图的其他人会看到它实时汇集在一起​​。他们可以添加、删除和更改卡片，每个人都可以看到其他人在做什么。您几乎可以“退后一步”并立即查看整面墙，这很方便，因为计算机屏幕只是您在墙上工作时可以看到的内容的一个小入口。

The person using Cardboard is creating a map at the same time as David Hussman, one of Cardboard’s creators, maps on a wall. Others who are sharing the same map from other locations see it come together in real time. They can add, remove, and change cards, and everyone can see what everyone else is doing. You can virtually “step back” and look at the entire wall at once, which is handy because computer screens are just a tiny portal on what you could see if you were working at a wall.

远程协作时，使用允许每个人同时查看、添加和组织模型的工具。

When collaborating remotely, use tools that allow everyone to see, add to, and organize the model concurrently.

令人高兴的是，我看到越来越多的工具进入市场，它们理解并支持一起工作以建立共同的理解。这是一件好事。

Happily, I’m seeing a lot more tools enter the market that understand and support working together to build shared understanding. This is a good thing.

记住

Remembering

当我们一起努力达成一致时，我们应该保留我们创建的任何模型或示例的副本以用作度假照片——以帮助我们记住我们讨论过的所有细节。像 Atlassian 的 Confluence 这样的工具提供了丰富的 wiki，不仅可以存储文字，还可以存储图片和视频。一起工作后拍摄并保存照片和视频是最快的记录方式之一。

When we’ve worked hard together to get on the same page, we should be keeping copies of whatever models or examples we’ve created to use as vacation photos—to help us remember all the details we’ve discussed. Tools like Atlassian’s Confluence offer a rich wiki for storing not just words, but also pictures and video. Taking and keeping pictures and videos after working together is one of fastest ways to document.

Atlassian 的这些人正在这样做。他们在墙上工作后拍了一张照片，并将其上传到他们的 wiki 以妥善保管。

These folks at Atlassian are doing just that. They’ve snapped a picture after working at a wall, and uploaded it to their wiki for safekeeping.

使用工具发布图片、视频和文本，以帮助您保留和记住您的对话。

Use tools to post pictures, videos, and text to help you retain and remember your conversations.

我个人喜欢保持低保真并在墙上保留信息，但如果我担心清洁工在晚上将其取下，我会拍照并保存以防万一。如果我要与不能在房间里的人分享信息，即使是虚拟的，我也会拍摄一段短视频，介绍墙上的模型，并将其张贴在其他人可以看到的地方。

I personally like staying lo-fi and keeping information on the wall, but if I worry at all about a cleaning person taking it down at night, I’ll photograph and keep it just in case. If I’m sharing information with people who couldn’t be in the room, even virtually, I’ll shoot a short video stepping through the model on the wall and post that where others can see it.

追踪

Tracking

工具最擅长的事情之一就是完成我们计划要做的所有工作，并让我们跟踪其进度。工具可以很好地跟踪对我们来说很乏味的数字——比如我们确切的开始时间、完成时间以及还有多少事情要做。当我们定期跟踪我们正在做的事情时，更好的工具将为我们产生有用的见解。

One of the things that tools most excel at is taking all the work we’ve planned on doing, and letting us track its progress. Tools are great at keeping track of the numbers that are tedious for us—things like exactly when we started, when we finished, and how much we’ve got left to do. The better tools will generate useful insights for us as we routinely track what we’re doing.

这是Atlassian的JIRA产品生成的累积流程图。这是一张图表，显示我们正在做的工作及其随时间的状态。这是一张我不愿意手工制作的图表。

This is a cumulative flow diagram generated by Atlassian’s JIRA product. It’s a chart that shows the work we’re doing and its state over time. And it’s a chart I would hate to produce by hand.

对于单一的、并置的团队和小型项目，墙就可以了。但是，如果您有更大的团队在不同的物理位置工作，并且项目运行时间更长，请使用工具来跟踪所有细节。

For single, collocated teams and small projects, the wall will do just fine. But, if you’ve got larger teams working from different physical locations, and longer-running projects, use a tool to keep track of all the details.

使用工具来排序、跟踪和分析进度。

Use tools to sequence, track, and analyze progress.

诀窍是为正确的工作使用正确的工具。不要尝试使用非常棒的跟踪工具来建立共同的理解。不要费力地在白板上进行复杂的分析。

The trick is using the right tool for the right job. Don’t try to use a really great tracking tool to build shared understanding. And don’t struggle to do complex analysis on a whiteboard.

保持事情简单快速，尽可能多地在索引卡和白板上工作一直是敏捷的理想。我向你保证，如果你能保持小而快，避免使用不必要的工具，你会更快乐。但请记住：这些工具只是达到目的的一种手段。接下来，我们需要谈谈卡片之后会发生什么。

It’s been an Agile ideal to keep things simple and fast, to stay working on index cards and whiteboards as much as possible. And I promise you if you can stay small and fast and avoid unnecessary tools, you’ll be happier. But remember: those tools are just a means to an end. Next, we’ll need to talk about what happens after the card.

在进行对话并写下有助于我们记住这些对话的细节并写下确认之后——也就是说，我们同意我们将检查以确认我们已经完成的事情——我们终于准备好做一些事情了：

After having conversations, and writing down details that’ll help us remember those conversations, and writing down confirmation—that is, our agreement about the things we’ll check to confirm we’re done—we’re finally ready to make something:

这里最重要的是，所有这些人的脑袋里都装着同一张图：他们 一起谈话时构建的图。

The most important thing here is that all these people are armed with the same picture in their heads: the picture they built while talking together.

我要在这里暂停一下。

I’m going to pause here for effect.

现在，我要慢慢说下一部分，所以你应该慢慢读。

Now, I’m going to say this next part slowly, so you should read it slowly.

如果你和一群人一起工作来理解应该构建什么，并且如果你已经记录了构建它需要知道的所有重要事情，那么你可能很想把它交给其他人。毕竟，当您查看这些信息时，它对您来说一清二楚。但不要自欺欺人。你很清楚，因为你真正聪明的大脑正在填写所有没有写下来的细节。你的大脑非常擅长它，以至于你很难发现可能遗漏了什么。请记住，这些细节是您的度假照片，而不是他们的。

If you and a group of people have worked together to understand what should be built, and if you’ve documented all the important things someone needs to know to build it, you may be very tempted here to hand it off to someone else. After all, when you look at the information, it’s crystal clear to you. But don’t fool yourself. It’s clear to you because your really smart brain is filling in all the details that aren’t written down. Your brain is so good at it that it’s hard for you to detect what could be missing. Remember, those details are your vacation photos, not theirs.

分享故事相当简单。真正理解故事的人，以及收集到的有助于讲述故事的信息，只需要花一点时间将故事复述给下一个需要学习的人。现在，这应该比你们一起做出艰难决定的早期对话要快得多，因为希望你们不需要重新做出决定。使用所写的内容来帮助讲述故事。说话并指着图片。让您的听众提出问题并对图片进行修改以帮助她记住。帮助她将与故事相关的信息变成她自己的度假照片。

Sharing stories is reasonably simple. Someone who does understand the story, and the information collected that helps tell the story, needs only spend a little time retelling the story to the next person who needs to learn. Now, this should go lots faster than early conversations where you worked together to make tough decisions, since hopefully you won’t need to remake them. Use what’s written to help tell the story. Talk and point to pictures. Let your listener ask questions and make changes to the pictures that help her remember. Help her turn the information associated with the story into her own vacation photos.

我经常在这里看到一个讨厌的反模式。有些人认为，既然团队中的任何人都可能会拿起故事并为之工作，那么团队中的每个人都应该参与到每一次对话中。也许你在这家公司工作。你会知道的，因为你会听到很多人抱怨会议太多了。顺便说一句，“会议”通常是我们用来指代无效协作的委婉说法。

There’s a nasty anti-pattern I often see here. Some think that since anyone in a team might pick up the story and do work on it, everyone on the team should be involved in every conversation. Perhaps you work at this company. You’ll know it because you’ll hear lots of people complaining that there are way too many meetings. By the way, “meeting” is often the euphemism we use for unproductive collaboration.

两到五人的小组最适合进行有效的讨论和决策。这是晚餐谈话的大小。您知道，如果您有一群朋友共进晚餐，那么在只有几个人的情况下很容易进行一次对话。但只要超过五个人，它就会成为真正的努力。

Effective discussion and decision making goes best with small groups of two to five. It’s dinner conversation sized. You know that if you have a group of friends sharing a meal, it’s easy to hold a single conversation when there are just a few of you. But any more than about five people is where it becomes a real effort.

让小组一起做决定，然后通过持续的对话与其他人分享结果。

Let small groups work together to make decisions, and then use continued conversations to share the results with everyone else.

如果你在团队中，你们将一起工作，并对你正在构建的内容和原因有共同的理解。当你们一起工作时，你们会一直进行对话，因为你们永远不会考虑所有事情。但是当软件完成后，你们会一起回来讨论它。

If you’re on the team, you’ll all work together armed with shared understanding about what you’re building, and why. As you work together, you’ll keep having conversations because you never think of everything. But when the software is done, you’ll all come back together and talk about it.

现在是祝贺自己工作出色的好时机。看到真正的进步真是太棒了。在传统的软件开发中，看到辛勤工作成果的机会要少得多，而且很少作为团队共享。在像 Scrum 这样的典型敏捷流程中，您将每隔几周在冲刺结束时进行一次产品评审。在最健康的团队中，团队成员经常聚在一起检查他们完成的工作。但你需要超越展示和讲述。祝贺自己之后，花点时间对自己所做工作的质量进行简短而认真的反思。

This is a good time to congratulate yourselves on a job well done. It’s pretty cool to see real progress. In traditional software development, the opportunities to see the results of your hard work can come a lot less frequently, and they’re rarely shared as a team. In a typical Agile process like Scrum, you’ll be sharing every couple of weeks at an end-of-sprint product review. In the healthiest of teams, team members get together frequently to inspect their work as it’s done. But you’ll need to go beyond show and tell. After congratulating yourselves, take time for a short but serious reflection on the quality of the work you did.

说到质量，我先从这三个方面开始讨论：

When talking about quality, I start with discussions of these three aspects:

我有一些坏消息要告诉你。你可能会发现你认为应该改变你所做的事情。

I have some bad news for you here. You’re likely to find things you believe should change about what you’ve done.

将两个问题分开会有助于每个人的理智。第一：我们是否建造了我们同意建造的东西？然后：如果这是我们同意建造的，既然我们看到了，我们是否应该做出一些改变？

It’ll help everyone’s sanity to separate out two concerns. First: did we build what we agreed to build? And then: if it’s what we agreed to build, now that we see it, should we make some changes?

每个人都会在一开始就一起努力工作，以弄清楚要构建什么来解决用户的问题并且构建起来是经济的。您将尽最大努力确定要检查的内容以确认它已完成。检查所有这些事情，如果你已经完成那么多，祝贺你自己。你得到的正是你同意你想要得到的。

Everyone will have worked hard together at the outset to figure out what to build that would solve users’ problems and be economical to build. You’ll have done your best to identify the things to check to confirm that it’s done. Check all those things, and congratulate yourselves if you’ve accomplished that much. You got exactly what you agreed you wanted to get.

现在，我脑海中浮现出一些滚石乐队的老歌歌词。如果你知道这首歌，请跟着哼唱：“你不能总是得到你想要的。但是，如果你尝试一下，你可能会发现，你得到了你需要的东西。” 具有讽刺意味的是，软件恰恰相反。

Now, here’s where some old Rolling Stones song lyrics play in my head. If you know the song, hum along: “You can’t always get what you want. But, if you try sometime, you just might find, you get what you need.” The irony with software is that it’s exactly the opposite.

你们将共同努力，就你们想要的达成一致。而且，如果您与一个有能力的团队一起工作，您会发现您可以非常擅长获得它。但是，只有在看到它之后，您才能更好地评估它是否是您需要的。这很糟糕。但不要责怪自己——事情就是这样。

You’ll work together to agree on what you want. And, if you’re working with a competent team, you’ll see that you can get pretty good at getting it. It’s only after seeing it, though, that you can better evaluate if it’s what you need. This sucks. But don’t blame yourselves—that’s just the way it works.

但是，您确实有办法修复它。它首先写一张卡片，上面写着你对软件进行哪些更改以修复它的想法。当然，如果您一开始就打算做对，这就很糟糕了。也许 Mick Jagger 终究是对的。也许你真正需要的是了解第一次就正确是一种冒险的策略——尤其是在软件领域。

You do, however, have a way of fixing it. And it starts by writing a card with your ideas about what to change in the software to fix it. This, of course, sucks if you’d planned on being right the first time. Maybe Mick Jagger was right after all. Maybe what you really needed was to learn that being right the first time is a risky strategy—especially in software.

对不起。我有更多的坏消息。

I’m sorry. I’ve got even more bad news.

实际上，最初编写卡片并开始整个循环的人很可能不是每天都会使用该软件的人。最初编写这张卡片的人，以及一起工作的整个团队，可能相信他们已经做到了——他们已经为目标用户所面临的挑战构建了完美的解决方案。

In reality, the person who originally wrote the card and who started this entire cycle is likely not the person who will use the software every day. The person who originally wrote the card, and the entire team who worked together, may believe they’ve nailed it—that they’ve built the perfect solution to the challenges their target users have.

不要自欺欺人。

Don’t fool yourself.

如果我们一起加入这个团队并且我们很聪明，我们会将软件带给用户并与他们一起测试。这也不是展示和讲述。我们将通过观察他们使用该软件来实现他们通常需要使用该软件来实现的真实目标来进行测试。

If we’re on this team together and we’re smart, we’ll take the software out to users and test it with them. This isn’t show and tell, either. We’ll test by watching them use the software to reach a real goal they’ll normally need to accomplish using the software.

当某人使用您帮助构建的软件时，您是否曾与她坐在一起？回想一下你第一次这样做。进展如何？当时我不在房间里和你在一起，但我敢打赌，事情并没有像你预期的那样进行。

Have you ever sat with someone as she uses software you’ve helped build? Think back to the first time you did. How did it go? I wasn’t in the room with you at the time, but I’m willing to bet that it didn’t go the way you expected.

如果您曾经在用户使用您的产品时坐在她旁边，您就会明白我的意思。如果您从未这样做过，那就去做吧。

If you’ve ever sat next to a user as she uses your product, you know what I mean. If you’ve never done this, then do it.

您需要对实际购买、采用和使用您的产品的人进行测试，这些人会以一定的频率定期使用您的产品。我经常等到我构建了一些软件——足够他们可以用它来完成他们以前无法完成的事情。无论您采用何种频率，都不要让超过几周的时间没有看到真正的用户与该软件进行交互。

You’ll need to test with the people who’ll actually buy, adopt, and use your product at some regular frequency. I often wait until I’ve built up a bit of software—enough that they could use it to accomplish something they couldn’t before. Whatever frequency you adopt, don’t let more than a couple weeks go by without seeing a genuine user interact with the software.

团队中的每个人都不需要与用户在一起。事实上，如果每个人都这样做，它会让用户感到厌烦。但是在那里建立同理心，你不会得到任何其他方式。看到人们努力使用您的产品是一种强大的动力，尤其是当您确信他们不需要时。如果您在场，请通过向他人讲述故事来与他人分享您的所见所闻。

Everyone on the team doesn’t need to be there with users. In fact, it’ll kind of creep the users out if everyone is. But being there builds empathy that you won’t get any other way. It’s a powerful motivator to see people struggling to use your product, especially when you were so confident they wouldn’t need to. If you were there, share what you saw with others by telling stories back to them.

与用户一起测试后，您将确定要解决的问题和改进软件的明显方法。对于其中的每一件事，您都应该写一张故事卡，其中包含您改进软件的想法。

After testing with users, you’ll identify problems to fix and obvious ways to improve the software. And for each one of those things, you should write a story card with your ideas for improving the software.

如果您一直相信使用故事可以阻止您的团队编写糟糕的软件，那么您至少对了一半。事实上，聪明人之间的所有对话都集中在理解问题上——以及我们正在构建的产品如何解决它——对制造更好的产品大有帮助。但我们需要承认，构建软件与在流水线上工作不同。您不只是像几分钟前构建的那样再构建一个小部件。我们创建软件支持的每个新故事都是新事物。

If you’d labored under the belief that using stories would stop your team from writing bad software, you were at least half right. In fact, all the conversations between smart people focused on understanding the problem—and how what we’re building solves it—go a long way toward making a much better product. But we need to acknowledge that building software isn’t the same as working on an assembly line. You’re not just building one more widget like the one you built a few minutes ago. Each new story we create software to support is something new.

敏捷开发社区中的一位杰出人物是我的前面提到的朋友，Alistair Cockburn，他曾经告诉我，“对于你写的每一个故事，你需要将三个故事放入积压的故事中。”

One of the luminaries in the Agile development community is my aforementioned friend, Alistair Cockburn, who once told me, “For every story you write, you need to put three into your backlog of stories.”

我问他为什么，他说：“你就是这样。”

I asked him why, and he said, “You just do.”

我问：“另外两个应该写什么？”

I asked, “What should I write on the other two?”

“你写什么并不重要。”

“It doesn’t matter what you write.”

“你是什么意思？” 我问：“我必须在上面写点东西！ ”

“What do you mean?” I asked, “I have to write something on them!”

阿利斯泰尔回答说：“好吧，如果你必须在上面写点什么，那就在第一张卡片上写下你想要的东西，然后在第二张卡片上写下‘修复第一张卡片’。” 然后在第三张卡片上，写下“修复第二张卡片”。如果你不为每个故事绕过这个循环 3 次，你就不是在学习。”

Alistair replied, “Well, if you have to write something on them, then write what you want on the first card, and on the second card write ‘Fix the first card.’ Then on the third card, write ‘Fix the second one.’ If you aren’t going around this cycle three times for each story, you’re not learning.”

在传统流程中，学习被称为范围蔓延或不良需求。在敏捷过程中，学习是目的。您需要计划从您构建的所有内容中学习。而且你需要计划在相当多的时间里犯错。

In a traditional process, learning gets referred to as scope creep or bad requirements. In an Agile process, learning is the purpose. You’ll need to plan on learning from everything you build. And you’ll need to plan on being wrong a fair bit of the time.

Eric 在第 3 章中使用的策略帮助他构建较小的解决方案并继续迭代它们直到它们可行。Eric 指望从每个版本中学习。

Eric’s strategy used in Chapter 3 helped him build smaller solutions and continue to iterate them until they were viable. Eric counted on learning from every release.

蒙娜丽莎策略_Mike 和 Aaron 在第 4 章中使用的方法帮助他们将每个故事分成更小、更薄、无法交付的部分，这样他们就可以更快地学习并明智地管理他们的交付预算以按时完成。

The Mona Lisa strategy used by Mike and Aaron in Chapter 4 helped them slice every story down into smaller, thinner, undeliverable bits so they could learn sooner and manage their delivery budget wisely to finish on time.

这些都是很好的学习策略。试试那些。发明你自己的。但请不要假设你总是对的。我保证你会失望的。

These are both great learning strategies. Try those. Invent your own. But please don’t assume you’re always right. I promise you’ll be disappointed.

2011 年，故事的作者肯特·贝克 (Kent Beck) 通过对敏捷宣言的修订开启了首批精益创业会议之一。如果我这样做了，那可能就是亵渎神明。但他是它的创造者之一，所以他应该知道。他修改了阅读有关工作软件的价值：

In 2011, Kent Beck—the creator of the story—opened one of the first Lean Startup conferences with his revision of the Agile Manifesto. If I’d done it, it might have been blasphemy. But he’s one of its creators, so he should know. He revised the value about working software to read:

如果您还记得第 3 章，经过验证的学习是来自精益创业过程的超级有价值的概念。那里的关键词是学习。使它成为有效学习的原因是讨论我们想要学习什么作为制作某物的一部分，然后回过头来考虑后果——反思我们学到了什么或没有学到什么。我们意识到的一件事是，我们并不总是需要构建软件来学习。但我们通常确实需要制作或做某事。

If you remember from Chapter 3, validated learning is the super-valuable concept that comes from the Lean Startup process. The key word there is learning. What makes it validated learning is discussing what we want to learn as part of making something, and then going back and considering the consequences—reflecting on what we learned or didn’t learn. And one of the things we’re realizing is that we don’t always need to build software to learn. But we do usually need to make or do something.

我喜欢用故事来推动我们所做的工作，以构建简单的原型，或者计划我们正在做的采访或观察用户的工作。我也喜欢谈论这些事情的人物、内容和原因。我喜欢在我们制作之前就我们将制作的东西达成一致。我回顾了这样做的后果，以考虑我们学到了什么。

I like using stories to drive the work we do to build simple prototypes, or to plan the work we’re doing to interview or observe users. I like talking about the who, what, and why for those things, too. I like agreeing on what we’ll make before we make it. And I look back at the consequences of having done it to consider what we’ve learned.

故事地图对于将我们的大产品或功能创意分解成更小的部分很有用。第 3章和第 4 章是关于将这些较小的部分分割成可构建的块，其中每个块都专注于学习一些东西。但是有一种不同的方法可以分解你需要注意的事情，并在你的头脑中保持独立。这是我们将故事分解成我们制作某物的计划的工作。这就是我们将在下一章中讨论的内容。

Story maps are useful for breaking up our big product or feature ideas into smaller parts. Chapter 3 and Chapter 4 were about slicing up those smaller parts into buildable chunks where each chunk was focused on learning something. But there’s a different way to break things down that you need to be aware of, and to keep separate in your head. It’s the work we do to break down a story into our plan to make something. That’s what we’ll talk about in the next chapter.

在我们的讨论中，Sydnie 正在考虑如何制作蛋糕。她必须这样做，这样她才能弄清楚她是否能及时赶到。到了做蛋糕的时候，她会列出一份她需要做的事情的清单——比如测量面粉、糖、黄油、鸡蛋和牛奶。她需要混合、烘烤、装饰，并可能执行其他一些我不知道的绝密步骤。我怀疑她对不同种类的蛋糕有不同的食谱，还有一张清单，列出了每个蛋糕在装进盒子准备拿走之前必须做的事情。如果 Sydnie 写下她必须做的所有事情的清单，她就会有一个充满特定蛋糕烘焙任务的工作计划。

During our discussion, Sydnie is thinking about how she’ll make the cake. She has to so she can figure out if she can make it in time. When it comes time to make the cake, she’ll have a list of things she’ll need to do—things like measuring flour, sugar, butter, eggs, and milk. She’ll need to mix, bake, decorate, and likely perform some other top-secret steps I don’t know about. I suspect she has different recipes for different kinds of cakes, and a checklist of things she has to do for every cake before it’s stuck in a box and ready to pick up. If Sydnie wrote down the list of all the things she has to do, she’d have a work plan full of specific cake-baking tasks.

当有人将故事带给开发团队时，也会发生同样的事情。他们一起决定具体要构建什么，开发团队制定他们的工作计划，由许多开发任务组成。开发团队包括测试人员、UI 设计人员、技术编写人员或创建软件所需的任何人员和技能，因此任务不仅仅与编码有关。而且，就像 Sydnie 在电话中与我交谈时没有制定她的计划一样，开发团队也不太可能在故事对话期间制定他们的计划。但他们会倾听、做笔记、画图并收集制定计划所需的大量细节。至少，这是我们希望的方式。

The same thing happens when someone brings a story to a development team. Together they make decisions on specifically what to build, and the development team creates their work plan, composed of lots of development tasks. The development team includes testers, UI designers, technical writers, or whatever people and skills are necessary to create the software, so the tasks aren’t all about coding. And, just like Sydnie didn’t create her plan while she talked with me on the phone, the development team won’t likely create their plan during the story conversation. But they will listen, take notes, draw pictures, and gather lots of the details they’ll need to create their plan. At least, that’s the way we hope it goes.

与 Sydnie 交谈时，我不会讲关于糖和面粉的故事。除非我的目标是建造一个烤箱，否则我不会讲关于烘焙的故事。当您讲述有关软件的故事并收集故事名称列表时，您在讲述故事时会想象您最终将拥有的软件。您不仅要想象软件，还要思考和谈论谁在使用它以及为什么使用它。Sydnie 并没有拘泥于蛋糕的细节，她问我蛋糕是给谁吃的，我女儿喜欢什么，聚会会有多少人，还有很多信息帮助我们一起决定最好的蛋糕应该是什么。Sydnie 不只是询问蛋糕要求，我们还共同努力决定制作我们都喜欢的蛋糕的最佳方式。这就是故事对话背后的真正精神。

When talking with Sydnie, I don’t tell stories about cups of sugar and flour. I wouldn’t tell a story about baking unless my goal was to build an oven. When you tell stories about software, and collect a list of story names as you do, you tell the story imagining the software you’ll have in the end. And you don’t just imagine the software—you think and talk about who uses it and why. Sydnie didn’t just stick to details about the cake, she asked me who it was for, what my daughter liked, how many people would be at the party, and lots of information that helped us decide together what the best cake should be. Sydnie wasn’t just asking for cake requirements, we were working together to decide on the best way to create a cake we’d all love. That’s the real spirit behind a story conversation.

但只有一件事。这里经常出现的问题是，当我们开始向真正有能力将我们的愿景变为现实的人讲述这个故事时，我们很快就会发现我们的故事所描述的软件非常庞大。好吧，上面写着它的卡片和其他卡片一样大。我们的用户试图通过它达到的目标对他们来说可能并不比其他人更重要，但是当我们谈论它时，我们意识到编写实现该目标所需的软件需要花费大量时间。

But there’s just one thing. Often what goes wrong here is that, when we start telling the story to people who are really capable of turning our vision into reality, we quickly figure out that the software our story describes is really big. Well, the card it’s written on is the same size as all the others. And the goal our users are trying to reach with it may be no more important to them than others, but it’s when we talk about it that we realize it’ll take a lot of time to write the software necessary to reach that goal.

当我和 Sydnie 谈论我的蛋糕时，同样的事情也可能发生。我本可以想象一个精致的蛋糕需要 Sydnie 没有的蛋糕盘，或者她没有掌握的蛋糕制作和装饰技术。结果将是一个我买不起的蛋糕，而且 Sydnie 也无法在我女儿生日前送出。

The same thing could have happened when I was talking with Sydnie about my cake. I could have imagined an elaborate cake that calls for cake pans Sydnie doesn’t have, or cake-building and decorating techniques she’s not mastered. The result would be a cake I can’t afford, and one that Sydnie couldn’t predictably deliver before my daughter’s birthday.

在第 7 章中，我指出，当我们考虑的解决方案过于昂贵时，我们需要退后一步，真正审视我们正在努力解决的问题，以及我们正在努力实现的结果。我们需要考虑其他选择。这是获得较小蛋糕或馅饼的一种方法？

In Chapter 7, I pointed out that when the solution we’re thinking of is too expensive, we need to step back and really look at the problems we’re trying to solve, and the outcomes we’re trying to achieve. And we’ll need to consider other alternatives. That’s one way to get a smaller cake—or maybe a pie?

但是，如果它真的很大，而且我们负担得起，那么就没有理由把它分解得更小，对吧？好吧，实际上是有的。对于软件，尤其是通过将事物分成更小的部分来构建，我们可以更快地看到和衡量进展。这有助于花钱的人不那么紧张。而且，就像第 4 章的蒙娜丽莎策略一样，它可以帮助制造产品的人评估零件，以确保我们走在正确的轨道上。

But, if it’s really big, and we can afford it, then there’s no reason to break it down any smaller, right? Well, actually, there is. With software, especially, by building things in smaller parts, we can see and measure progress sooner. This helps the people spending money feel a bit less nervous. And, as in Chapter 4’s Mona Lisa strategy, it helps the people making the product evaluate parts to make sure we’re on the right track.

有一个分解大故事的技巧，它可以帮助我在脑海中记住蛋糕的比喻。如果你喜欢蛋糕，现在你可能会饿了——尤其是当你想象中的蛋糕特别好吃的时候。对于那个很抱歉。

There’s a trick to breaking down large stories, and it helps me to keep the cake metaphor in my head. If you like cake, by now you might be getting hungry—especially if the cake you’re imagining is a particularly tasty one. Sorry about that.

假设我们的故事描述了对更大蛋糕的需求，例如可以供数百人食用的超大婚礼蛋糕。如果是这样，那么它不再只是几杯面粉和糖，而是麻袋面粉和糖。大多数人以同样的方式分解软件。不仅仅是一点用户界面、一点业务逻辑和一点数据库交互，每个都有很多。但请记住，软件不是蛋糕。量两磅面粉所花的时间并不比量两杯面粉所花的时间多。但是为 20 个屏幕构建用户界面比仅仅为 2 个屏幕构建用户界面要花费更多的时间。因此，如果团队使用看似合乎逻辑的简单分解结构，他们很容易将软件分解为数周的前端开发、数周的业务逻辑开发等。当我们使用该策略时，我们需要很长时间才能“尝到任何蛋糕”，可以这么说。所以不要那样做。

Let’s say our story describes a need for a lot bigger cake, like a super-giant wedding cake that will feed hundreds of people. If so, then it isn’t just cups of flour and sugar anymore, it’s sacks of flour and sugar. Most people break down software the same way. Instead of just a little user interface, a little business logic, and a little database interaction, there’s lots of each. But remember that software isn’t cake. It doesn’t take that much more time to measure two pounds of flour than it does to measure two cups of flour. But building the user interface for 20 screens takes a lot more time than for just 2 screens. So, if teams use the simple breakdown structure that seems logical, they get tempted to break software down into weeks of frontend development, weeks of business logic development, and so on. When we use that strategy, it takes a long time before we can “taste any cake,” so to speak. So don’t do that.

现在这个比喻真的要在这里崩溃了，但再坚持一分钟。处理一个大软件蛋糕的方法是将它分解成许多小蛋糕。每一个都是可交付的，每一个都有相似的食谱，加一点糖，一点面粉，一两个鸡蛋，等等。

Now the metaphor is really going to break down here, but stick with me for just one more minute. The way you approach a big software cake is to break it down into lots of little cupcakes. Each one is deliverable, and each one still has a similar recipe, with a little sugar, a little flour, an egg or two, and so on.

好的，现在让我们再认真一点。软件不是蛋糕。它可能变得巨大、极其昂贵且风险极大。在我撰写本文时，我刚刚在早间电视新闻中听到另一个故事，即美国政府未能通过网站为人们注册医疗保健。事后批评很容易。但也很容易看出，在比喻婚礼上送蛋糕之前，没有人尝过蛋糕——至少没有人尝过。那个半生不熟的蛋糕毁了聚会。

OK, now let’s get a little more serious again. Software isn’t cake. It can get huge, horrendously expensive, and horribly risky. As I write this text, I’ve just heard yet another story on the morning television news of the US government’s failed website to sign people up for healthcare. It’s easy to criticize after the fact. But it’s also easy to see that no one tasted that cake before it was served at the metaphoric wedding—at least no one with any taste. And that half-baked cake ruined the party.

如果您在更传统的软件开发领域工作过一段时间，您可能学会了将大型软件分解为大型计划。我知道我做到了。将大的东西分解成看起来不太像您要交付的成品的小块似乎有悖常理。您会知道，在组合这些软件部分时，您必须对每个部分进行一些重写和调整才能将它们组合起来。但请记住——您有很多充分的理由这样想。最大的挑战之一是避免因太晚未看到、使用或“品尝”软件而带来的风险。你正在把大事分解成小的、可评估的部分，这样你就可以更快地学习。

If you’ve worked in more traditional software development for a while, you likely learned to break down big software into big plans. I know I did. It’ll seems counterintuitive to break down something big into smaller pieces that may not quite look like the finished product you’re trying to deliver. You’ll know that as you combine these pieces of software, you’ll have to do a bit of rewriting and adjusting of each piece to combine them. But remember—you’re thinking this way for lots of good reasons. One of the biggest is to avoid the risks involved with not seeing, using, or “tasting” the software too late. You’re breaking big things down to small, evaluable parts so you can learn sooner.

如果我分解蛋糕的目的是为了早点品尝它或早点看到装饰，我最好烤一些小纸杯蛋糕来帮助我更快地学习。我会烤一些不同口味的，这样我就可以品尝到所有的口味，选择我最喜欢的，并确信我做出了正确的选择。如果我关心颜色和装饰，我会想看看不同风格装饰的不同纸杯蛋糕，然后选择最好的那一款。

If I were breaking down a cake with the goal of tasting it sooner or seeing the decoration sooner, I’d do well to bake small cupcakes that help me learn sooner. I’d bake some in a number of different flavors so I could taste them all, choose the one I liked best, and be confident I’d made the right choice. If I were concerned about colors and decoration, I’d want to look at different cupcakes decorated in different styles, and choose the one that was best.

对于软件，纸杯蛋糕是工作软件的一部分，允许用户评估他们是否可以有效地完成用户任务。它们可能是帮助暴露技术风险的软件部分。但是每件作品都可以帮助我们学到一些东西。

With software, the cupcakes are portions of working software that allow users to evaluate if they can effectively complete a user task. They may be portions of software that help expose a technical risk. But each piece helps us learn something.

但是一堆纸杯蛋糕不是结婚蛋糕——是吗？^{[ 11 ]}

But a pile of cupcakes isn’t a wedding cake—or is it?^[11]

软件不是蛋糕。我们构建的每个软件都以一种蛋糕无法做到的方式组合成一个更大的工作产品。

Software isn’t cake. And every piece of software we build does combine into one larger working product in a way that cake can’t.

我的朋友 Luke Hohman 有一句愚蠢的口头禅是你可以送“半个烤蛋糕，而不是半生不熟的蛋糕”。半个烤好的蛋糕可能不足以满足一场婚礼的需要，但足以让每个人品尝并期待剩下的蛋糕。

One of the silly mantras that comes from my friend Luke Hohman is that you can deliver “half a baked cake, not a half-baked cake.” Half a baked cake may not be enough to feed a wedding party, but it’s enough to taste and leave everyone looking forward to the rest of the cake.

我通过谈论 Sydnie 的蛋糕和突破的想法结束了最后一章蛋糕变成小蛋糕。但软件的有形性要差得多，而且尺寸不能像蛋糕那样以英寸、厘米、盎司或克来衡量。

I ended the last chapter by talking about Sydnie’s cake and the idea of breaking big cakes into little cakes. But software is a lot less tangible, and size can’t be measured in inches, centimeters, ounces, or grams like it can with a cake.

最初的想法是，用户或需要某物的人可以在卡片上写下他需要的东西，然后我们可以就此进行对话。需要它的人不知道如何将他的需求表达为只需要很短时间就能形成的东西。它需要大小。

The original idea was that a user or a person who needs something could write what he needed on a card and then we could have a conversation about that. The person who needed it didn’t figure out how to express his need as something that would take only a short time to develop. It was need sized.

到了编写软件的时候，编写、测试和集成软件的小部分有很大好处。如果我能更快地看到和测试小零件，我就能衡量我们建造的速度和我们获得的质量。如果我可以将大的东西分成许多小的部分，那么我的团队就可以更容易地同时挑选和构建零件。一个好的经验法则是将故事分解成需要几天时间来构建和测试的东西。

When it comes time to write software, there’s big benefit in writing, testing, and integrating software in small parts. If I can see and test small parts sooner, I can measure how fast we’re building and what kind of quality we’re getting. If I can divide something big into lots of smaller parts, it makes it a little easier for my team to pick up and build parts concurrently. A good rule of thumb is to break down stories to something that takes a couple of days to build and test.

但是，从商业角度来看，以多种功能捆绑的形式向客户和用户发布软件可能是最有意义的。如果您要发布一个全新的产品，那么第一个捆绑包可能会非常大。这是我之前称为最小可行解决方案的捆绑包，它专注于为目标用户群实现特定结果。理想情况下，企业应该努力更频繁地发布更多这些内容——以推动它们更接近于匹配用户的需求规模，或者更小、更具体的业务成果。但是，如果您有大量不同的客户使用您的产品，并且您没有支持更连续的发布过程的基础架构或业务模型，那么您的业务发布可能会更大。

But, from a business perspective, it may make the most sense to release software to customers and users in bundles of multiple features. If you’re releasing a whole new product, that first bundle can be pretty large. This is the bundle I called a minimum viable solution earlier, and it’s focused on reaching specific outcomes for a target group of users. Ideally, businesses should be striving to release more of these more frequently—to push them closer to matching users’ need size, or a smaller and more specific business outcome. But, if you’ve got a large, diverse group of customers using your product, and you don’t have an infrastructure or business model that supports a more continuous release process, then your business’s releases may be bigger.

我可以说故事没有“合适的大小”，但事实并非如此。合适的尺寸是与您正在进行的对话相关的尺寸。

I could say there’s no “right size” for stories, but that’s not true. The right size is the size that’s relevant to the conversation you’re having.

这些大故事包含许多小故事，小故事又包含更多小故事。根据您的谈话对象，您可能必须将谈话“卷起”到更高的层次。

Those big stories contain lots of smaller stories, which in turn contain lots more smaller stories. Depending on who you’re talking to, you might have to “roll up” your conversation to a higher level.

把故事想象成岩石。如果我拿一块非常大的石头，把它放在地板中间，然后用木槌敲打它，让它裂成 30 块，我们就称那 30 块石头为石头。如果你拿起其中一块较小的石头并用木槌敲打它，它就会碎成小块。我们也称这些作品为岩石。现在，我们可能会对给这些岩石起的名字变得有创意，比如boulder或pebble。但我不确定什么时候某样东西不再是一块巨石，而开始只是一块普通的老石头。它看起来像一块石头，直到它落在你的脚上。然后感觉就像一块巨石。

Think of stories like rocks. If I were to take a really big rock and put it in the middle of the floor and hit it with a mallet where it broke into 30 pieces, we’d call those 30 pieces rocks. If you took one of those smaller rocks and hit it with a mallet, it would break into smaller pieces. We’d call those pieces rocks, too. Now, we might get creative about the names we give these rocks, like boulder or pebble. But I’m never sure when something stops being a boulder and starts being just a plain old rock. It looks like a rock until it’s dropped on your foot. Then it feels like a boulder.

我的破石工具是一把大木槌。这很有效。

My rock-breaking tool is a big mallet. And that works pretty well.

大故事分解成小故事，小故事又可以分解成更小的故事。就像岩石一样。而且，无论大小如何——无论多小——它们仍然是一个故事。但是，我们用来分解故事的最佳工具是什么？没错：这是对话。有时只需要一点点思考就可以做到，但如果您与其他人进行对话和协作，那么您就是在传播共同的理解。

Big stories break down into smaller stories, and those smaller stories can be broken down to even smaller stories. Just like rocks. And, at every size—no matter how small—they’re still a story. But what’s the best tool we use for breaking down stories? That’s right: it’s conversation. Sometimes just a little thinking will do it, but if you use conversation and collaboration with someone else, then you’re spreading the shared understanding.

现在软件人员，我也是其中之一，对这里缺乏精确性感到不舒服。在我合作过的大多数组织中，都会出现按大小对故事进行分类的语言。但它又开始提出“巨石与鹅卵石”的问题。当你是一个被石头砸中的人时，关于大小的精确度最重要，这可以解释为什么软件人员热衷于对他们的故事进行分类。

Now software people, and I’m one of them, are uncomfortable with the lack of precision here. In most organizations I’ve worked with, language will emerge to classify stories by size. But it starts to raise the “boulders versus pebbles” question again. The precision about size matters most when you’re the one being hit with the rock, which could explain why software people get wrapped up in classifying their stories.

如果你在你的组织中创造语言，不要试图过于精确。关于故事中的内容以及它应该有多大的摆动是有意的。它为我们提供了在整个开发周期中使用这个简单想法所需的灵活性。

If you create language in your organization, don’t try to be too precise. The wiggliness about what’s in a story and how big it should be is intentional. It gives us the flexibility we need to use this simple idea throughout the development cycle.

史诗是一个常用术语（我不确定最初是谁创造的）用于描述大用户故事，有点像boulder是大石头的好用词。老实说，我花了很多年才习惯将我们正在构建的重要内容称为故事，但我现在明白为什么要这样称呼它们了。我仍在为epic一词而苦苦挣扎。我听到我的英语文学老师将史诗描述为一个英雄与邪恶作战的故事——比如贝奥武夫、阿喀琉斯或佛罗多——通常是在某种魔法武器或众神的帮助下。但是，我离题了……

Epic is a common term (I’m not sure who coined it originally) used to describe big user stories, sort of like boulder is a good term for a big rock. Now I’ll be honest with you that it took me years to get comfortable referring to the important stuff we were building as stories, but I understand now why they’re called that. I’m still struggling with the term epic. I hear my English Literature teacher describing an epic as a story about a hero battling evil—like Beowulf or Achilles or Frodo—usually with some sort of magic weapon or the assistance of the gods. But, I digress…

为一个大故事取一个术语是可以的，但要小心。史诗一词有时被用作武器。我经常看到一个开发团队成员告诉某个业务人员、产品经理、用户或有求必应的人，他的故事是史诗，而不是故事。这通常是以一种表明故事作者做错了什么的语气说的，导致她认真考虑对开发团队成员进行打击。所以，如果你是团队成员，请不要用史诗这个词来训斥别人。对于应该富有成效的对话来说，这是一个糟糕的开始（而且可能是过早的结束）。

It’s OK to have a term for a large story, but watch out. The term epic sometimes gets used as a weapon. I’ve often seen a development team member tell someone who is a businessperson, a product manager, a user, or someone who’s asking for something, that his story is an epic, not a story. This is usually said in a tone that indicates the storywriter has done something wrong, causing her to seriously consider sucker-punching the development team member. So, please, if you are a team member, don’t use the term epic as a stick to reprimand someone else. It’s a bad start (and, possibly, a premature ending) to what should be a productive conversation.

请记住，史诗是大故事，从业务、客户或用户的角度来看可能大小合适——而不是从开发的角度来看。共同努力打破他们。但是要保留史诗，因为你需要和人们谈论它，以及它分解成的所有详细故事。

Remember, epics are big stories that may be the right size from a business, customer, or user perspective—just not from a development perspective. Work together to break them down. But keep the epic around because you’ll need to speak to people about it, and all the detailed stories it broke down into.

如果您使用的是支持敏捷开发的电子工具，它可能会使用史诗的概念作为可以拆分为许多较小的子故事的大父故事。

If you’re using an electronic tool that supports Agile development, it’ll likely use the concept of an epic as a big parent story that can be split up into lots of smaller child stories.

使用术语主题来描述一组故事，将它们组合在一起很有用。当你开始打破常规——分解那些大故事并将它们组织成人们想要、可以使用并且有能力建造的产品——你最终会得到许多小故事。我认为主题是一个袋子，我可以用它来收集一堆相关的故事。我可以使用主题来收集下一个版本所需的一堆故事、同一功能的一部分、与特定类型的用户相关或以其他方式相关。但我的比喻有点不对劲，因为同一个故事可以有两个不同的主题，但同一块石头不能放在两个不同的袋子里。

Use the term theme to describe a group of stories that it’s useful to group together. As you start rock breaking—breaking down those big stories and organizing them into products that people want, can use, and can afford to build—you’ll end up with lots of smaller stories. I think of a theme as a sack I can use to collect a pile of stories that are related. I could use a theme to collect a bunch of stories that are needed for a next release, part of the same feature, relevant to a particular type of user, or related in some other way. But my metaphor is slightly broken since the same story can be in two different themes, but the same rock can’t be in two different sacks.

如果您使用帮助组织敏捷故事组的可用工具之一，它可能支持将故事捆绑成一个主题的概念。您可能只是根据主题的实际情况来引用主题：您的下一个版本、功能或与特定类型用户相关的故事。

If you use one of the available tools that help organize groups of Agile stories, it may support the concept of bundling stories up into a theme. You might simply refer to the theme by what it really is: your next release, the feature, or the stories relevant to a particular type of user.

术语史诗和主题已经进入敏捷生命周期管理工具，进入一些特定的命名敏捷方法，并进入用于讨论故事的通用语言。因此，您需要了解并理解它们。

The terms epic and theme have found their way into Agile lifecycle management tools, into some specific named Agile approaches, and into the common language used to discuss stories. For that reason, you’ll need to know and understand them.

现在，让我们搁置这些条款；忘了我什至提到过他们。至少有一小会儿。让我们退后一步，看看整个破土动工的生命周期。在那个周期中，我们将从大创意开始，您可以将其视为大石头，然后将它们一直移动到小块工作软件。然后将这些小块的工作软件重新组合成客户和用户想要的功能、产品和版本。

Now, let’s set aside those terms; forget I even mentioned them. At least for a little while. Let’s step back and take a look at the whole rock-breaking lifecycle. In that cycle we’ll start with big ideas, which you can think of as the big rocks, and move them all the way through to small pieces of working software. And then reassemble those small pieces of working software into features, products, and releases that customers and users want.

从远处看，这个破岩循环看起来像这样：

From a distance, that rock-breaking cycle looks like this:

现在，让我们深入了解细节。

Now, let’s dig into the details.

故事的旅程始于一个想法。它可能是新功能或全新产品的想法。这可能是我们希望改进我们已有功能的更改。这可能是我们需要解决的问题。但我会使用机会这个词，因为它是我们创造我们将从中受益的东西的机会。我建议您列出并列出这些机会。我称它们为机会积压。

The story’s journey starts as an idea. It may be an idea for a new feature, or a whole new product. It could be a change we’d like that would improve a feature we already have. It could be a problem we need to solve. But I’ll use the term opportunity, because it’s an opportunity for us to make something that we’ll benefit from. I suggest you name and build a list of these opportunities. I call them an opportunity backlog.

我们的第一个好故事对话是一个更高层次的、谁-什么-为什么的讨论。我们的大目标是做出走/不走的决定。Go 并不意味着我们会构建它。这意味着我们将继续进行更深入的讨论，以真正理解这个故事。但如果我们从一开始就发现这是个坏主意，我不想继续花费大量时间来做这件事。No-go 是一种礼貌的表达“垃圾”的方式。所以，让我们称之为前进/垃圾决定。记住，总是有太多东西需要建造，在浪费每个人太多时间之前扼杀一个平庸的机会应该值得庆祝。

Our first good story conversation is a higher-level, who-what-why discussion. And our big goal is to make a go/no-go decision. Go doesn’t mean we’ll build it. It means we’ll go forward with deeper-dive discussions to really understand the story. But I don’t want to move forward with spending lots of time doing this if we can detect that it’s a bad idea from the outset. No-go is a polite way of saying “trash.” So, let’s call this a go-forward/trash decision. Remember, there’s always too much to build, and killing a mediocre opportunity before it wastes too much of everyone’s time should be celebrated.

既然您已选择继续前进，那么是时候进行更深入的挖掘了。使用发现来找到值得构建的解决方案。并且不要忘记真正最小化该解决方案。力求使它尽可能小而有价值。

Now that you’ve chosen to go forward, it’s time to dig much deeper. Use discovery to find a solution worth building. And don’t forget to really minimize that solution. Seek to make it as small and valuable as you can.

在发现过程中，您将真正深入挖掘：

During discovery you’ll really dig deep into:

有大量的实践可以在发现过程中提供帮助，尤其是故事映射。故事映射可以帮助您了解当今人们的工作方式，然后映射您关于创建解决方案后事情将如何改变的想法。

There are a huge number of practices that can be helpful during discovery, especially story mapping. Story mapping can help you understand how people work today, and then map your ideas about how things will change for them after your solution is created.

发现是认真研究我们的假设并努力验证它们的关键所在。这可能会采取更深入的分析形式，以了解业务规则或外部法规。它应该采取直接花时间与客户和用户交流的形式，以了解他们的工作方式。它应该涉及构建解决方案的原型并与目标受众一起验证它们。它还应包括构建技术原型以排除技术风险。

Discovery is where it’s critical to look hard at our assumptions and to do work to validate them. This may take the form of deeper analysis to understand business rules or outside regulations. It should take the form of spending time directly with customers and users to understand how they work. It should involve building prototypes of your solution and validating them with your target audience. And it should include building technical prototypes to chase out technical risks.

庆祝该解决方案中您可以安全丢弃的每一部分，或者将积压的机会推迟到其他地方处理。我们的机会可能是大石头。但这些岩石里面是钻石和贵金属。分解那些石头，把那些真正有价值的部分从那些只是石头的东西中分离出来。并庆祝扔掉那些东西。

Celebrate every part of that solution that you can safely trash, or push back to a backlog of opportunities to deal with elsewhere. Our opportunities may have been big rocks. But inside those rocks were diamonds and precious metals. Break down those rocks and separate those really valuable parts from the stuff that’s just rock. And celebrate trashing that stuff.

在整个发现过程中，您可以选择构建有助于您学习的小东西——特别是 UI 或架构原型。

Throughout discovery, you may choose to build small things that help you learn—specifically, UI or architectural prototypes.

Spike是一个术语，用于表示我们以明确的学习目标进行的一些开发或研究。这是一个来自极限编程社区的术语，用于描述可能不会产生我们选择发布的软件的工作。使用故事来描述让你的团队构建一些东西来学习的峰值。

Spike is a term used for bits of development or research we do with the explicit goal of learning. It’s a term that came from the Extreme Programming community to describe work that may not yield software we choose to ship. Use stories to describe spikes that get your team building something to learn.

在您确信您已经获得了应该构建并发布给客户和用户的故事的一小部分之后，就该将它们推进到交付阶段了。导致有价值的产品发布的故事子集就是我所说的发布积压。

After you’re confident you’ve got that small subset of stories you should build and release to customers and users, then it’s time to move them forward into delivery. That subset of stories that leads to a valuable product release is what I refer to as a release backlog.

我们的机会可能始于大石头。发现对话打破了它们并将岩石与贵金属分开。但是，如果我们能够将这些部分分解成尽可能小的部分，那么交付将以最快和最有效的方式进行——请记住，每个部分仍然需要是我们可以构建和学习的东西。要做到这一点，需要进行更多的对话，深入得多。

Our opportunities may have started as big rocks. Discovery conversations broke them down and separated the rock from the precious metals. But delivery will move fastest and most effectively if we can keep breaking down those pieces into the smallest parts possible—keeping in mind that every part still needs to be something we can build and learn from. It’s going to take a lot more conversations that dive into a lot more depth to do that.

我想象一台很酷的岩石破碎机：我在一侧装载这些包含所有贵金属的大而粗糙的岩石，然后在另一侧吐出大小恰到好处的小岩石，准备进入下一个开发周期。我要给这台机器贴上故事车间机器的标签，它的名字准确地描述了我们将要做的事情。

I picture a cool rock-breaking machine: on one side I load these big, rough rocks that contain all those precious metals, and then the other side spits out small, just-right-sized rocks ready to go into the next development cycle. I’m going to label this machine the story workshop machine, and its name describes exactly what we’ll do.

我们将与开发人员和测试人员以及团队中将构建软件的其他人进行深入讨论，以真正挖掘细节。这些是我们“最后的最佳对话”——我们真正需要就确认达成一致的对话，或我们构建的软件的小部分的验收标准——因为下一步是构建它们。因为我们知道它是打破软件的对话，所以我们将使用这些对话将我们的故事调整到合适的大小和形状，以放入下一个开发冲刺或迭代。

We’ll use deep-dive discussions with developers and testers, and everyone else on the team who’ll build the software, to really dig into the details. These are our “last best conversations”—the conversations where we really need to agree on confirmation, or the acceptance criteria for the small parts of software we build—because the next step is building them. Since we know that it’s conversations that break up software, we’ll use these conversations to get our stories into the right size and shape to put into the next development sprint, or iteration.

我喜欢将这些最后的最佳故事对话称为故事工作坊，因为每个人都知道会议没有效率，但研讨会是为了完成工作。它们可以根据需要发生，几乎每天都会发生。有时它们会在计划会议期间同时发生。在敏捷流程 Scrum 中，它们可能发生在所谓的待办事项梳理或待办事项改进会议期间。不管你怎么称呼这些讨论，都进行讨论。

I like to call these last best story conversations story workshops because everyone knows that meetings are unproductive, but workshops are for getting work done. They can happen as needed, almost every day. Sometimes they happen all at once during a planning session. In the Agile process Scrum, they may happen during what’s called a backlog grooming or backlog refinement session. Whatever you call these discussions, have them.

故事车间机器为下一个生产线——敏捷交付机器提供动力。这就是我想象的敏捷交付机器真正发挥作用的地方。我们在一侧放置这些小的、常规大小的故事，而在另一侧放出一个经过优化的、可工作的软件——或者你的故事所描述的任何东西。

The story workshop machine feeds the next in line—the Agile delivery machine. And here’s where I picture the Agile delivery machine really kicking in. In one side we put these small, regular-sized stories, and out the other side comes a polished, working bit of software—or whatever it is that your story described making.

无论您多么努力，即使是您最近的最佳故事对话也无法预测您在开始构建后将学到的一切。计划每天进行大量频繁的临时故事对话。在日常站立会议中提出对它们的需求。

No matter how hard you try, even your last best story conversations won’t have predicted everything you’ll learn once you start to build. Plan to have lots of frequent, ad hoc story conversations every day. Bring up the need for them in your daily standup meetings.

如果您是一名开发人员，并且您陷入故事讨论中的细节不足以回答您现在的问题，请跳起来找人交谈以继续您的讨论。你不能在这里责怪糟糕的要求。请记住，在开始之前，您与其他人一起确定了构建所需的所有知识。但我们都是人。错过一些东西是可以的。

If you’re a developer and the details you trapped in story discussions aren’t enough to answer questions you have now, jump up and find someone to talk with to continue your discussion. You can’t blame bad requirements here. Remember that, before you started, you worked with others to identify all you’d need to know to build. But we’re all human. It’s OK to miss some things.

如果您是产品负责人、用户体验设计师、业务分析师或其他帮助决定构建内容的人之一，请不要害怕从办公桌上站起来查看开发进展情况。我保证，一旦您看到有用的东西，您就会看到有用的东西。而且，更有可能的是，使它工作的人可以使用一点反馈。

If you’re a product owner, UX designer, business analyst, or one of the other folks who helped decide what to build, don’t be afraid to get up from your desk to see how development is going. I promise that once you see something working, you’ll see something useful. And, more than likely, the person getting it working could use a little feedback.

当那些完成的工作软件从敏捷交付机器中滚出来时，是时候让那些帮助描述要构建什么的人和构建它的人停下来仔细看看我们构建的东西了。

When those finished bits of working software roll out of the Agile delivery machine, it’s time for the people who helped describe what to build, and the people who build it, to pause and look closely at what we built.

请记住，这些并不是真正的机器。你和你的同事都不是机器上的齿轮。而你刚刚发现的所有这些部分并不是完全相同的小部件。他们都是不同的。

Remember, these aren’t really machines. And you and the people you work with aren’t cogs in a machine. And all those pieces you just turned out aren’t exactly the same widget. They’re all different.

停下来真正看看构建的解决方案的质量。反思你的计划有多有效。你真的完成了你的预期吗？需要更长的时间吗？更短？或者关于你的想象？并真正谈论“机器”的工作情况。是时候对您的工作方式进行调整或改变，以更可预测地获得质量更好的东西了。

Stop and really look at the quality of the solution built. Reflect on how effectively you planned. Did you really finish what you expected? Did it take a lot longer? Shorter? Or about what you imagined? And really talk about how well the “machine” is working. It’s time to make adjustments or changes to the way you work to get better-quality stuff out more predictably.

Scrum 中的第一次评估称为冲刺评审和回顾。无论您将这些时间称为停下来、回顾和反思，请确保您拥有它们。

This first pass at evaluation in Scrum is called a sprint review and retrospective. Whatever you call these times to stop, review, and reflect, make sure you have them.

请记住，您正在构建的内容不适合您——至少通常不适合您。您需要将它展示在用户和客户面前，以了解他们的感受。对于这些人中的一些人，他们所看到的只是原型、线框图或文字描述。看到和触摸到有用的东西，真的可以让他们评估自己是否得到了正确的东西。

Remember that what you’re building wasn’t for you—at least not usually. You’ll need to get it in front of users and customers to see how they feel about it. For some of these folks, all they’ll have seen is a prototype, or a wireframe, or a textual description. Seeing and touching something working really lets them evaluate whether or not they’ve got the right thing.

但是从敏捷交付机器中出来的这些小碎片中的每一个都可能不足以让他们分辨。在我的心智模型中，我想象每一块都在一个秤上堆积起来。这是一种老式秤，另一边有配重。在我的配重上是足够的这个词；也就是说，足以与用户和客户进行测试，并让他们和我们学到一些东西。

But each of these little pieces that came out of the Agile delivery machine may not be enough for them to tell. In my mental model I picture each of those pieces piling up on a scale. It’s one of those old-style scales with a counterweight on the other side. On my counterweight is the word Enough; that is, enough to test with users and customers and for them and us to learn something.

通常足够意味着整个屏幕或屏幕流，允许用户完成任务或达到有意义的目标。而且我不想做一个节目并告诉用户。我不是要他们说，“那太好了。” 我正在寻求学习——学习的形式通常是“这不太对”和“现在我真的在使用它，如果……会更好”

Usually enough means a whole screen, or a flow of screens, that allows users to complete a task or reach a meaningful goal. And I don’t want to do a show and tell with users. I’m not looking for them to say, “That’s great.” I’m looking to learn—and learning usually takes the form of “That’s not quite right” and “Now that I really use it, it would be better if…”

您的组织中可能还有其他人对您正在构建的软件有既得利益。他们可能不是每天都会使用它的人，但他们担心软件会尽快交付给这些人——或者至少在你说的时候。

There are likely others in your organization who have a vested interest in the software you’re building. They may not be the people who’ll use it every day, but they’re concerned that the software is going to be delivered to those people as soon as possible—or at least when you said it would be.

使用评论向他们展示到目前为止的产品。使用评论来谈论您与更大计划的关系。请记住：他们可能对您是否满足了您构建的一堆单个小零件的计划不感兴趣。他们感兴趣的是最小可行解决方案的进展——因为这是我们可以发布并真正从外部世界获得一些价值的最小部分。所以说那个。与他们分享您对用户或客户进行的测试的结果。他们也会有兴趣了解这一点。

Use a review to show them the product so far. Use the review to talk about where you are in relationship to your bigger plan. Remember: they likely aren’t interested in whether you meet your plan for the bunch of single, small parts you built. What they’re interested in is progress on the minimum viable solution—because that’s the smallest part we could release and really get some value from in the outside world. So speak to that. Share with them the results from tests you’ve done with users or customers. They’ll be interested in learning that, too.

我在所有这一切结束时想象了最后一个规模。在这个规模上，我把我们一起审查过的部分堆积起来，与客户和用户一起测试，并让我公司的利益相关者看到。巧合的是，这个量表与我们在几步之前使用的量表非常相似——与用户和客户一起评估。与另一个秤一样，在配重上它表示“足够” ——但这次它意味着足以释放给那些客户和用户以产生我正在寻找的结果。当规模达到平衡时，将其发布给客户和用户。

I picture one last scale at the end of all this. On this scale I pile up the parts we’ve reviewed together, tested with customers and users, and made visible to stakeholders in my company. Coincidentally, this scale is very similar to the one that we used a couple of steps ago—evaluate with users and customers. As with this other scale, on the counterweight it says Enough—but this time it means enough to release to those customers and users to produce the outcome I’m looking for. When that scale balances, release it to customers and users.

但不要就此止步。你还有东西要学。如果您像第 3 章中的埃里克一样，学习是您的主要目标，那么您将需要使用指标来了解人们是否以及如何使用您的产品。您需要使用面对面的对话来了解他们为什么使用或不使用它。如果您预测人们会使用您的产品，并且他们和您的公司将从中受益，请不要只是假设。使用指标和对话来真正了解正在发生的事情。

But don’t stop there. You’ve still got something to learn. If you were like Eric in Chapter 3, learning was your primary goal, so you’ll need to use metrics to learn if and how people use your product. You’ll need to use face-to-face conversations to learn why they do or don’t use it. If you predicted that people would be using your product, and they and your company would be benefiting from it, don’t just assume that. Use metrics and conversations to really learn what’s happening.

如果这是一个项目，你就完成了——因为你交付了它。但你刚刚做了一些事情。这是一个产品。产品的生命从交付之时就开始了。当你开始关注人们用你的产品做什么时，我保证你会找到改进它的机会。把它们写下来，并将它们反馈到这个模型的开头。

If this were a project, you’d be done—because you shipped it. But you just made something. It’s a product. And a product’s life starts when it’s delivered. When you start paying attention to what people are doing with your product, I promise you’ll find opportunities to improve it. Write those down, and feed them back into the beginning of this model.

这才是真正的生活循环——或者至少是故事中的生活。

That’s the real circle of life—or at least, the life of a story.

这是一个很大的突破。那么究竟应该由谁来进行所有这些岩石破碎工作呢？很高兴你提出这个问题，因为这就是下一章的内容。

And that’s a lot of rock breaking. So exactly who is supposed to do all that rock breaking? I’m glad you asked, because that’s what the next chapter is about.

Marty Cagan在他的著作《灵感：如何创造客户喜爱的产品》（SVPG 出版社）中描述了产品经理识别有价值、可用和可行的产品的责任。当我第一次读到这些话时，我在脑海中描绘了一个简单的维恩图，其中我们想要的解决方案是对我们公司和我们的客户有价值的东西的交集，可供用户使用，并且在我们的时间和工具的情况下是可行的有。

In his book Inspired: How to Create Products Customers Love (SVPG Press), Marty Cagan describes the responsibility of a product manager to identify a product that’s valuable, usable, and feasible. When I first read these words, I pictured in my head a simple Venn diagram where the solution we want is an intersection of what’s valuable to our company and our customers, usable by its users, and feasible to build given the time and the tools we have.

但这里可能不太明显的是，要真正确定处于最佳位置中心的解决方案，需要了解我们的业务、我们的客户、我们的用户和我们使用的技术的人员之间的协作——而不仅仅是了解这些事情，但对解决方案的成功负责。这些人实际上与利益相关者、客户和用户交谈；他们实际设计和测试用户界面；他们实际上设计和测试使产品工作的代码。

But what may not be dead obvious here is that, to really identify the solution in the center of that sweet spot will take collaboration between people who understand our business, our customers, our users, and the technology we use—and not just understand those things, but take responsibility for the success of the solution. These people actually speak with stakeholders, customers, and users; they actually design and test user interfaces; they actually design and test the code that makes the product work.

还记得敏捷开发中的误解，即单个产品所有者或产品经理决定构建什么吗？一个人拥有找到有价值的可用可行最佳点所需的业务、用户界面设计和工程技能，即使不是不可能，也是很少见的。这就是为什么最有效的组织使用小型、跨职能的探索团队来共同寻找正确的解决方案。正如我们在前一章中讨论的那样，将发现视为突破性的工作。我们所做的工作是将一个故事从一个模糊的大想法转变为我们可以构建的小而具体的东西。

Remember that misconception in Agile development where a single product owner or product manager decides what to build? It’s rare if not impossible for a single person to possess the business, user interface design, and engineering skills necessary to find that valuable-usable-feasible sweet spot. That’s why the most effective organizations use small, cross-functional discovery teams that work together to find that right solution. As we discussed in the preceding chapter, think of discovery as rock-breaking work. It’s the work we do to move a story from a big vague idea to something small and specific we can build.

团队的理想规模是 2 到 4 人——晚餐对话的规模，这样成员们可以快速建立共识。

The ideal size for the team is two to four people—dinner-conversation-sized so the members can quickly build shared understanding.

这个团队应该由对她的业务愿景和战略以及她的产品所服务的市场有深刻理解的产品所有者或产品经理领导。这个核心团队包括了解用户、乐于与他们合作以了解他们的工作方式并且可以绘制和创建简单的 UI 原型的人员。它还包括来自将构建产品的团队的高级工程师。此人需要了解系统的当前架构，并深入了解可用于解决棘手问题的新工程方法。这里真正的秘密在于，最具创新性的解决方案通常来自对业务问题和用户问题具有洞察力的工程师。

This team should be led by a product owner or product manager who has deep understanding of her business’s vision and strategy, and of the market her product serves. This core team includes someone who understands users, is comfortable working with them to learn about the way they work, and can sketch and create simple UI prototypes. It also includes a senior engineer from the team who’ll build the product. This person needs to understand the current architecture of the system and have insight into newer engineering approaches that could be used to solve tough problems. The real secret here is that the most innovative solutions often come from the engineer supplied with insight about the business problem and the users’ problems.

一个有凝聚力的发现团队是一个强大的、快速移动的专家组，他们可以快速发现问题并验证解决方案。我经常听到triad这个词来形容这个核心团队。在我最近访问位于悉尼的 Atlassian 时，您在第 8 章中遇到的 Sherif指着三个并排的座位。他解释说，“这就是三合会所在的地方。” 三合会周围的区域摆满了桌子和电脑，团队的其他成员就坐在那里。当发现团队中有两个人、四个人甚至更多人时，我会听到“三合一”一词，因为我们谈论的是三个问题——有价值、可用和可行——而不是三个机构。

A cohesive discovery team is a powerful, fast-moving group of experts who can find problems and validate solutions quickly. I often hear the term triad used to describe this core team. On my recent visit to Sydney-based Atlassian, Sherif, whom you met in Chapter 8, pointed to three seats close together. He explained, “This is where the triad sits.” The area around the triad was filled with desks and computers where the rest of the team sat. I hear the term triad used when there are two people, four people, or even more on the discovery team, since it’s the three concerns—valuable, usable, and feasible—we’re talking about, not three bodies.

有效的发现不仅可以协调与开发团队的协作，还可以协调业务利益相关者、主题专家、客户和最终用户的协作。这是一项艰巨的工作，除了每个团队成员带来的特定专业知识外，还需要一流的沟通和协调技巧。

An effective discovery coordinates collaboration with not only the development team, but also business stakeholders, subject matter experts, customers, and end users. It’s tough work that requires top-notch communication and facilitation skills, in addition to the specific expertise each team member brings in.

现在，这是真正的秘密。对于任何重要的产品，都需要一个团队来构建它。为了保持产品愿景清晰，确保团队构建的解决方案具有凝聚力，并帮助每个人朝着同一个方向前进，好的产品领导者至关重要。这些领导者中的佼佼者专注于帮助每个人掌握主人翁精神。在一个健康的故事驱动的环境中，你会看到很多故事对话一直在进行。他们中的许多人不需要那里的产品负责人。

Now, here’s the real secret. For a product of any significance, it’ll take a team to get it built. To keep the vision of the product clear, ensure the solution the team builds is cohesive, and help keep everyone moving in the same direction, a good product leader is critical. The best of these leaders focus on helping everyone take ownership. In a healthy story-driven environment, you’ll see lots of story conversations going on all the time. And many of them won’t need the product leader there.

¡三个朋友！是 1986 年一部平庸的西部喜剧的名字，由 Steve Martin、Chevy Chase 和 Martin Short 主演。这部电影与敏捷软件开发和故事有什么关系？在故事研讨会期间，有一个更具战术性的合作者三合会很有价值。我不确定最初是谁给他们起了“三个朋友”的绰号，但是它似乎卡住了。^{[ 13 ]}（我敢肯定，如果有更多人看过这部电影，那就不会了。）

¡Three Amigos! is the name of a mediocre 1986 western comedy starring Steve Martin, Chevy Chase, and Martin Short. What does this film have to do with Agile software development and stories? There’s a more tactical triad of collaborators that’s valuable during story workshops. And I’m not sure who originally gave them the moniker “the three amigos,” but it appears to have stuck.^[13] (I’m sure if more people had seen the movie, it wouldn’t have.)

您可能还记得，故事研讨会是我对最后一次最佳对话的术语，在对话中我们具体决定要构建什么。这就是三个朋友进来的地方。

You might recall that story workshops is the term I give to that last best conversation where we decide specifically what to build. It’s here where the three amigos come in.

在最后一次最好的谈话中，我们确实需要考虑很多细节和实施的备选方案，因此我们需要团队中的一名开发人员来构建软件——理想情况下，是真正从事该软件工作的开发人员之一。

During this last best conversation, we really need to consider lots of details and alternatives for implementation, so we’ll need a developer from the team who’ll build the software—ideally, one of the developers who will actually work on it.

为了让这个小软件被认为已经完成，它需要进行测试，所以我们需要一个测试人员参与对话。测试人员——第一个朋友——通常会以批判的眼光看待讨论，比大多数人更早发现可能出错的地方。测试人员通常最擅长玩“What-About”游戏。

For this small piece of software to be considered done, it’ll need to be tested, so we’ll need a tester in the conversation. A tester—the first amigo—will often bring a critical eye into the discussion, spotting things that might go wrong sooner than most. The tester is often the best at playing the “What-About” game.

而且，当然，我们需要有人了解我们正在构建什么、它的用途以及我们为什么要构建它，因此我们需要该核心产品发现团队的一名成员。那个人就是第二个朋友。

And, of course, we’ll need someone who understands what we’re building, who it’s for, and why we’re building it, so we’ll need a member of that core product discovery team. That person is the second amigo.

在这个阶段，我们通常不会引入新的功能创意。我们可能已经在发现中这样做了。现在我们或多或少地致力于构建一些东西，所以明确了解该软件的外观和行为方式非常重要。因此，参与此对话的人通常是处理过这些细节的用户体验设计师或业务分析师。这是你的第三个朋友。

At this stage we’re often not introducing a new feature idea. We likely already did that back in discovery. Now we’ve more or less committed to build something, so it’s important to understand specifically how that software should look and behave. So often the person involved in this conversation is a user experience designer or business analyst who’s worked through those details. This is your third amigo.

该小组将研究细节并就故事的具体验收标准达成一致。通过这次对话，我们将对构建和测试软件所需的时间做出最佳估计。正是在这种对话中，我们经常决定将故事拆分为更小的、“大小合适”的开发故事——这些故事需要一到三天的时间来构建和测试。

This group will work through the details and agree on specific acceptance criteria for the story. It’s out of this conversation that we’ll have our best estimate of how long it will take to build and test the software. And it’s often in this conversation that we’ll make decisions to split the story into smaller, “right-sized” development stories—those stories that take one to three days to build and test.

当我们通过软件开发传递想法时，故事对话会不断发生。在每次谈话中，把有价值的、有用的、可行的都保留在讨论中。包括可以与这些事物交谈的人。通过让产品所有者对成功的、有凝聚力的产品负责来避免由委员会进行设计。

Story conversations happen continuously as we move ideas through software development. In every conversation, keep what’s valuable, what’s usable, and what’s feasible in the discussion. Include people who can speak to those things. Avoid design by committee by holding a product owner responsible for a successful, cohesive product.

客户端-供应商反模式

有一种讨厌的反模式妨碍了很好地使用故事。事实上，它会妨碍人们齐心协力做好任何事情。这是可怕的客户-供应商反模式。

There’s a nasty anti-pattern that gets in the way of using stories well. In fact, it can get in the way of people working together to do anything well. It’s the dreaded client-vendor anti-pattern.

在这种反模式中，对话中的一个人扮演客户角色，而另一个人扮演供应商角色。客户的工作是了解他想要什么，并向供应商解释细节。这就是我们所说的“要求”。供应商的工作是倾听、理解，然后通过技术方法思考来交付客户的要求。然后供应商给出她的估计——在软件术语中，这实际上意味着“承诺”，这也是为什么开发人员常常害怕在没有进行彻底调查的情况下给出估计的原因。

In this anti-pattern, one person in a conversation takes the client role, while the other takes the vendor role. It’s the client’s job to know what he wants, and to explain the details to the vendor. That’s what we call “requirements.” It’s the vendor’s job to listen, understand, and then think through a technical approach for delivering what the client asked for. The vendor then gives her estimate—which in software lingo actually means “commitment,” and is the reason why developers often fear giving estimates without thorough investigation.

可悲的是，故事的其余部分是可以预见的。

The rest of the story is sadly predictable.

每隔一段时间，估计就会非常准确，客户得到了他想要的，而他想要的实际上就是他需要的。

Every once in a while, the estimate is deadly accurate, and the client gets what he wanted, and what he wanted actually turns out to be what he needs.

但是，大多数时候，构建解决方案所需的时间比供应商预期的要长。供应商角色的人可以为延迟提出各种借口，包括她收到的要求中缺乏细节，或者只是“糟糕的要求”。客户可以责怪不准确的估计——似乎没有人注意到这是一种矛盾。当解决方案交付时，客户角色的人收到了他要求的东西，然后他有机会使用它并意识到这不是他需要的。他没有得到他想象的结果。

But, most of the time, constructing a solution takes longer than the vendor predicted. The person in the vendor role can cite all sorts of excuses for the delay, including lack of details in the requirements she was given, or just “bad requirements.” The client can blame inaccurate estimation—which no one seems to notice is an oxymoron. When the solution is delivered, and the person in the client role receives what he asked for, he then gets an opportunity to use it and realize it’s not what he needs. He doesn’t get the outcome he imagined he would.

这里真正的悲剧在于，客户角色的人比他能够预测解决问题的方法更能理解他的问题。了解技术的人通常是最有资格解决问题的人，因为她知道她所使用的技术可以提供怎样的帮助。更重要的是，大多数技术人员真诚地想要提供帮助。他们想知道他们正在建造的东西得到了很好的利用。

The real tragedy here is that the person in the client role understands his problem better than he’s able to predict what will solve it. And the person who understands the technology is often the most qualified to solve the problem because she knows how the technology she’s working with can help. What’s more, most technologists honestly want to help. They want to know the things they’re building are put to good use.

但是，在客户端-供应商反模式中，关于问题和解决方案的对话被关于需求的讨论和协议所取代。没有人赢。

But, in the client-vendor anti-pattern, conversations about problems and solutions are replaced by discussions and agreements about requirements. No one wins.

故事的目标之一就是打破这种反模式。

One of the goals of stories is to break this anti-pattern.

我们中的许多人拥有的一种关系在进展顺利时确实打破了这种反模式，那就是我们与医生的关系。尝试出现在您的医生办公室并向她提出您的“要求”。告诉她你想要开的处方和你想要安排的手术。如果她很好，她会微笑着说：“这很有趣；告诉我哪里痛。”

One kind of relationship many of us have that does break this anti-pattern when it goes well is the one we have with our doctor. Try showing up at your doctor’s office and giving her your “requirements.” Tell her the prescriptions you’d like written and the operations you’d like scheduled. If she’s nice, she’ll smile and say, “That’s interesting; tell me where it hurts.”

在我的脑海中，我描绘了一个连续体，其中一侧是waiter一词，另一侧是doctor一词。试着让你的工作关系更像一种良好的医患关系，而不是服务员-用餐者的关系。

In my head, I picture a continuum where on one side is the word waiter, and on the other is the word doctor. Try to make your working relationships much more like a good doctor-patient relationship, and much less like a waiter-diner’s.

如果您在更传统的 IT 环境中工作，产品负责人的概念可能看起来令人困惑。例如，如果您帮助银行构建关键系统，银行就会知道其真正的产品是向客户销售的银行服务。如果有人的正式头衔是“产品经理”，那么他的工作就是管理特定类型的银行账户或信贷产品。支持该服务产品的计算机系统只是拼图的一部分。通常，相同的 IT 基础架构支持许多不同的银行产品。可以理解的是，该银行并不将该基础设施视为一种产品，而且通常没有人拥有它。

If you work in a more traditional IT setting, the notion of a product owner may seem confusing. For example, if you help build critical systems for a bank, the bank knows its real products are the banking services it sells to its customers. If there is a person with the official title of “product manager,” it’ll be his job to look after a specific type of bank account or credit product. The computer systems that support that service offering are just a piece of the puzzle. And often that same IT infrastructure supports lots of different banking products. Understandably, the bank doesn’t see that infrastructure as a product, and there’s often no one who owns it.

在这些类型的组织中，业务分析师 (BA) 通常担任“需求收集”角色。他们将充当开发人员和业务利益相关者（如银行或保险产品的产品经理）之间的中介。当这些业务人员需要更改支持其产品的 IT 基础架构时，他们将与 BA 一起描述这些更改。这就是他们可能扮演客户角色的地方，因为 BA 扮演供应商角色，这就是反模式发挥作用的地方。

In these types of organizations, business analysts (BAs) are often placed in a “requirements gathering” role. They’ll act as an intermediary between the developers and the business stakeholders like the product manager of a banking or insurance product. When those businesspeople need changes to the IT infrastructure that supports their product, they’ll work with the BA to describe those changes. And here’s where they might take on the client role as the BA acts in a vendor role, and that’s where the anti-pattern kicks in.

在闲聊中，我的朋友大卫·哈斯曼 (David Hussman) 给了我一个更好的比喻来说明文学士与其业务利益相关者之间的关系——就像音乐制作人与乐队之间的关系一样。这对 David 来说是有道理的，他既是 Agile 大师，又是 1980 年代重金属乐队 Slave Raider 的前吉他手。他曾与制片人合作，自己也是制片人。在这种关系中，乐队带着激情进入音乐行业，希望有一些天赋，但他们不了解音乐行业或录制专辑的技巧。然而，生产者确实如此。制作人的工作就是帮助乐队录制出最成功的唱片。成功的制作人可以将才华横溢的天才变成具有商业可行性的唱片艺术家。

In casual conversation, my friend David Hussman gave me a better metaphor for the relationship the BA should have with his business stakeholders—the same relationship that a music producer has with a band. This makes sense coming from David, who’s both an Agile guru and ex-guitarist for the 1980s heavy metal band Slave Raider. He’s worked with producers, and been a producer himself. In that relationship the band comes to the music business with passion, and hopefully some talent, but they don’t know the music business or the mechanics of recording an album. The producer does, however. It’s the producer’s job to help that band make the most successful recording it can. Successful producers can turn raw talent into a polished, commercially viable recording artist.

作为 IT 环境中的业务分析师，这就是您的工作。了解您的业务利益相关者的愿景并帮助他们取得成功。你不能只是一个执行命令的人——你需要表现得更像一个医生。有时这意味着告诉您的利益相关者他们不想听到的事情。但是，如果您真诚地帮助他们取得成功，他们会看到并重视您的帮助。

As a business analyst in an IT context, that’s your job. Take the vision of your business stakeholders and help them make it a success. You can’t be just an order taker—you’ll need to behave more like a doctor. And sometimes this means telling your stakeholders things they don’t want to hear. But, if you’re sincere about helping them succeed, they’ll see it and value your help.

一种潜在的反模式是让业务利益相关者承担产品所有权的角色。我说潜力是因为如果业务人员得到其他团队成员的大量帮助和支持，渴望学习如何完成产品负责人的工作，以及完成它所需的时间，它就可以发挥作用。产品所有权不是一项微不足道的责任，不应被视为可以在业余时间完成的事情。与其强迫商人从事另一份工作，我建议您为他们找一个制作人来帮助他们取得成功。

One potential anti-pattern is to make the business stakeholder take on the product ownership role. I say potential because it can work if the businessperson has lots of help and support from other team members, an aspiration to learn how to do the job of a product owner, and the time it’ll take to do it. Product ownership isn’t a trivial responsibility, and shouldn’t be treated as something that could be done in your spare time. Instead of forcing another job on businesspeople, I’d recommend you find them a producer to help them succeed.

对于一个核心很简单的想法，整个故事变得非常混乱。如果有人告诉你软件开发——或任何产品开发，就此而言——很容易，那他们是在撒谎。

For an idea that at its core is simple, this whole story thing has gotten terribly messy. If anyone told you software development—or any product development, for that matter—was easy, they were lying.

故事同时包含很多东西。我们将使用这个词来指代卡片，指代我们构建的软件块，尤其是指我们必须就应该构建什么做出决定的那种对话。故事可以描述非常大的机会，或者本身对客户和用户来说不一定有意义的几乎微不足道的可交付成果。处理故事是一个持续的对话和讨论过程，将故事从大事分解为小事。通过所有这些对话，我们不仅关注我们可以构建什么，而且关注为谁构建以及为什么构建。故事地图只是帮助我们分解大事的方法之一，同时将对话的重点放在使用您产品的人以及他们成功的原因上。

Stories are many things at once. We’ll use the word to refer to the card, to the chunk of software we build, and especially to the kind of conversations we have to make decisions about what we should build. Stories can describe very large opportunities, or the almost insignificant deliverable pieces that by themselves aren’t necessarily meaningful to customers and users. Working with stories is a continuous process of conversation and discussion to break them down from big things to small things. And through all those conversations, we’re keeping not only what we could build in focus, but for whom, and why. Story mapping is just one of the ways to help us break big things down while keeping the focus of the conversation on the people using your product and what makes them successful.

如果这一切都开始变得有意义，那么你已经做出了重大的、必要的思维转变。这不是使用故事来记录需求的转变，而是转向更有效地与人合作，并共同专注于解决您创建的产品的实际问题。

If this is all starting to make sense, then you’ve made that big, necessary mindshift. It’s not a shift to use stories to document requirements, but a shift toward working with people more effectively, and together focusing on solving real problems with the products you create.

而且，我希望你会同意，这是一件美丽的事情。

And that, I hope you’ll agree, is a beautiful thing.

当我们想出点子时，这些点子往往非常宏大——但并非总是如此。用故事术语来说，你可以称它们为史诗，但我更愿意称它们为机遇。不管你怎么称呼它们，它们仍然是故事，我们关于它们的第一次对话的目的是决定是继续使用它们，还是丢弃它们。对于这些机会中的每一个，我们可以讨论：

When we come up with ideas, these ideas are often pretty big—but not always. In story lingo, you could call them epics, but I prefer to call them opportunities. No matter what you call them, they’re still stories, and the goal of the first conversations we have about them is to decide whether to move forward with them, or trash them. For each one of these opportunities, we can discuss:

这些故事的全部堆栈就是我所说的机会积压。我们还不确定是否应该建造它们，或者至少我们不应该建造它们。请记住，对于构建事物的想法总是比我们有时间的更多。找到与您组织的业务战略相一致的机会，并为客户和用户解决有吸引力的问题。进行足够的讨论以做出通过/不通过的决定。

The whole stack of these stories is what I call an opportunity backlog. We aren’t sure yet if we should build them, or at least we shouldn’t be. Remember, there are always more ideas for things to build than we’ll have time for. Find the opportunities aligned with your organization’s business strategy and that solve problems for customers and users that are compelling. Have enough discussions to make a go/no-go decision.

“开始”并不意味着“我们要建造这个东西”，它意味着我们将把机会推进到更深入的发现讨论中。在发现过程中，需要进行更多的讨论——可能与不在房间里的其他人进行讨论。如果这是一项新功能或全新产品，则需要更深入地了解客户和用户以及他们如何解决当今的问题。理想情况下，我们会直接与他们交谈。这将需要探索和制作不同解决方案的原型。根据您和您的团队所学到的知识，需要进行大量更深入的讨论，才能决定您具体需要构建哪些内容才能对客户、用户和您的组织有价值。而且，在所有这些工作之后，您仍然可能决定扼杀这个想法。

“Go” doesn’t mean “We’re gonna build this thing,” it means we’ll move the opportunity forward into deeper discovery discussion. During discovery, it’ll take a lot more discussion—probably with others not in the room. If this is a new feature or an entirely new product, it’ll take diving a lot deeper into customers and users and how they solve their problems today. Ideally, we’ll talk to them directly. It’ll take exploring and prototyping different solutions. It’ll take lots of deeper discussions in light of what you and your team learn to make a decision about what specifically you’ll need to build to be valuable to customers, users, and your organization. And, after all that work, you still might decide to kill the idea.

“不去”是机会讨论的一个很好的结果。请记住，要建造的东西总是比时间多。如果根据您的讨论，这个机会看起来没有希望，现在就把它扔掉。让支持该想法的人参与讨论可能是个好主意，希望他们能得出相同的结论。

“No-go” is a great result of an opportunity discussion. Remember, there’s always more to build than there is time. If the opportunity doesn’t look promising based on your discussion, trash it now. It may be a good idea to involve the people who championed the idea in the discussion so hopefully they come to the same conclusion.

您的小组可能没有足够的信息来做出继续或不继续的决定。如果是这种情况，请列出您需要学习的内容，然后一起开始工作以获取所需的信息。

Your group may not have enough information to make either a go or a no-go decision. If that’s the case, make a list of what you need to learn, and together get to work getting the information you need.

如果您仍然不能做出继续或不继续的决定，您可以随时将其放回机会待办列表中，稍后再讨论。这就是所谓的拖延症，我经常这样做。

If you still can’t make a go or no-go decision, you can always put it back into the opportunity backlog to discuss later. That’s called procrastination, and I do it a lot.

机会画布

在查看产品机会时，我使用 Marty Cagan 的机会评估模板作为起点。最近，我真的很喜欢使用canvas驱动的方法。查看业务模型的画布方法，如中所述亚历山大·奥斯特瓦尔德 (Alexander Osterwalder) 和伊夫·皮涅尔 (Yves Pigneur) 的著作《商业模式生成》 (Wiley) 是团队合作评估初创企业规模的有效方式。但对我和大多数与我共事的人来说，我们并不是在考虑开展新业务或推出新产品。我们经常考虑为我们的产品添加下一个重要功能。然而，这不应阻止您使用类似的画布方法来评估产品机会。

When looking at product opportunities, I’ve used Marty Cagan’s Opportunity Assessment template as my starting point. Recently, I’ve really come to like using a canvas-driven approach. The canvas approach to looking at business models, as described in Alexander Osterwalder and Yves Pigneur’s book Business Model Generation (Wiley), is an effective way for groups to work together to size up a startup business. But for me, and most of the people I work with, we’re not looking at starting a new business or launching a new product. We’re often looking at adding a next important feature to the product we have. That shouldn’t stop you from using a similar canvas approach to sizing up product opportunities, however.

画布在空间上组织信息。它很大而且都在一个地方，所以一个团队可以看到并使用它，这在幻灯片或打印文档中很难做到，而且组织允许你看到依赖关系。信息与它所依赖的其他信息相邻。

A canvas organizes information spatially. It’s big and all in one place so a group can see and work with it, which is hard to do in a slide or printed document, and the organization allows you to see dependencies. Information is adjacent to other information it depends on.

画布看起来像这样：

A canvas looks like this:

一起工作以画布格式收集信息如下所示：

And working together to gather information in a canvas format looks like this:

使用画布方法具有真正的好处，例如：

Using a canvas approach has real benefits like:

• 您可以在单一视图中查看商机的重要关注点。
• You can see the important concerns of an opportunity in a single view.
• 您可以看到这些问题之间的关系。
• You can see the relationships between these concerns.
• 通过协作创建画布来建立共同的理解、所有权和一致性，从而利用每个人的贡献。
• Building shared understanding, ownership, and alignment by working together collaboratively to create a canvas leverages everyone’s contribution.

作为产品发现团队，最初根据您今天的理解填写画布。让利益相关者、主题专家或您认为可以将重要信息带入对话的任何其他人参与进来。

As a product discovery team, initially fill out the canvas based on what you understand today. Involve stakeholders, subject matter experts, or anyone else you think can bring important information into the conversation.

使用便利贴可以在讨论进行时轻松改变主意。随着您了解更多，迭代改进画布。

Use sticky notes to make it easy to change your mind as discussion progresses. Iteratively improve the canvas as you learn more.

您可以从第一个框开始浏览画布，然后继续到第九个。但是，如果您对某个框没有很好的答案，请记录下您所知道的或您现在的假设，然后继续。

You could proceed through the canvas starting with the first box, and continue to the ninth. However, if you don’t have good answers for a box, record what you do know, or your assumptions now, and proceed.

在一个流程中填写画布，然后在另一个流程中阅读

Fill Out the Canvas in One Flow, and Read It in Another

画布中的框按逻辑顺序编号，您可以使用它来讨论机会。但是，如果您与其他人共享画布，您可能希望从左到右、从上到下阅读它。您会注意到在前面介绍的输出与结果模型中，从左到右的流程是从“现在”到“以后”。您还会注意到从上到下从用户需求到业务需求的移动。

The boxes in the canvas are numbered in a logical order you can use for discussing an opportunity. But, if you’re sharing the canvas with someone else, you may want to read it left to right, and top to bottom. You’ll notice the left-to-right flow is from “now” to “later” in the output versus outcome model introduced earlier. You’ll also notice that top to bottom moves from user needs to business needs.

这不是要填写的表格。相反，这是一组要讨论并反复完善您的理解的主题。请记住：“社区设计不是委员会设计。” 让很多人参与进来可以帮助每个人更快地学习，但最终，是否继续进行机会的决定落在产品所有者身上。最好的产品负责人利用他们的团队来帮助做出决定，并且通常会发现他们和他们的团队是一致的。

This isn’t a form to fill out. This is instead a set of topics to discuss and iteratively refine your understanding of. Remember: “design by community isn’t design by committee.” Involving lots of folks helps everyone learn faster, but ultimately, the go/no-go decision to proceed with an opportunity falls to the product owner. The best product owners leverage their teams to help make the decision, and usually find that they and their teams are in agreement.

这是机会画布中的空间流。

Here’s the flow of spaces in the Opportunity Canvas.

一、问题或解决方案

1. Problems or Solutions

理想情况下，我们应该从一个我们试图解决的明确问题开始。然而，世界很少是理想的。我们通常会得到一个功能或增强想法，然后需要回过头来理解问题。从你拥有的开始。

Ideally, we should start with a clear problem we’re trying to solve. However, the world is rarely ideal. We’re often given a feature or enhancement idea and then need to work backward to understand the problem. Start with what you have.

解决思路

Solution ideas

列出为目标受众解决问题的产品、功能或增强想法。

List product, feature, or enhancement ideas that solve problems for your target audience.

问题

Problems

您的解决方案解决了当今潜在用户和客户的哪些问题？

What problems do prospective users and customers have today that your solution addresses?

如果您正在构建一款娱乐产品，例如游戏或工具，以便在社交网络上分享有趣的东西，他们可能没有真正的“问题”需要解决，只是渴望获得娱乐。

If you’re building a product for entertainment like a game or tool to share fun stuff on a social network, they may not have a real “problem” to solve, just a desire to be entertained.

2. 用户和客户

2. Users and Customers

您的解决方案解决了哪些类型的用户和客户面临的挑战？寻找会影响他们使用产品的用户目标或用途的差异。根据这些差异将用户和客户分成不同的类型。将您的产品定位于“每个人”是个坏主意。

What types of users and customers have the challenges your solution addresses? Look for differences in users’ goals or uses that would affect their use of the product. Separate users and customers into types based on those differences. It’s a bad idea to target “everyone” with your product.

3. 今天的解决方案

3. Solutions Today

用户今天如何解决他们的问题？列出您的用户为满足他们的需求而拥有的竞争产品或解决方法。

How do users address their problems today? List competitive products or workarounds your users have for meeting their needs.

4.用户价值

4. User Value

如果您的目标受众有您的解决方案，那么他们如何才能以不同的方式做事呢？这对他们有何好处？

If your target audience has your solution, how can they do things differently as a consequence? And how will that benefit them?

5.用户指标

5. User Metrics

您可以衡量哪些用户行为将表明他们采用、使用您的解决方案并赋予其价值？

What user behaviors can you measure that will indicate that they adopt, use, and place value in your solution?

6.采用策略

6. Adoption Strategy

客户和用户将如何发现并采用您的解决方案？

How will customers and users discover and adopt your solution?

7. 业务问题

7. Business Problem

构建此产品、功能或增强功能可以为您的企业解决什么问题？

What problem for your business does building this product, feature, or enhancement solve for your business?

8. 业务指标

8. Business Metrics

该解决方案的成功将影响哪些业务绩效指标？这些指标通常是用户改变行为的结果。

What business performance metrics will be affected by the success of this solution? These metrics are often a consequence of users changing their behavior.

9.预算

9. Budget

您会预算多少资金和/或开发来发现、构建和改进此解决方案？

How much money and/or development would you budget to discover, build, and refine this solution?

我知道你的公司可能不会利用机会。事实上，如果你的公司和我合作过的公司一样，你就有了一张路线图，上面写满了你应该构建的东西。您甚至可以将它们视为您的“要求”。对任何这些东西做出不去的决定可能不是你的决定。事实是，我们真的不应该将所有这些聪明的想法都变成软件，无论拥有聪明想法的人的职位是什么。

I know your company probably doesn’t use opportunities. In fact, if your company is anything like those I’ve worked with, you’ve got a roadmap filled with stuff you’re supposed to build. You may even think of them as your “requirements.” Making a no-go decision on any of that stuff may not be your call. The truth is, we really shouldn’t turn all those clever ideas into software, no matter the job title of the person with the clever idea.

使用这第一次重大故事对话来构建您和您的团队可能要从事的工作。即使对通过/不通过问题的答案可能是“开始”，但请确保您在结束对话时就您正在解决的问题、为谁以及您的组织如何从构建软件中获益达成共识。

Use this first big story conversation to frame the work you and your team may be getting into. Even though the answer to the go/no-go question may be “Go,” make sure you leave the conversation with shared understanding about the problems you’re solving, for whom, and how your organization benefits from building software.

如果您或您团队中的任何人都不能决定继续利用这个机会，那么请确保您将可以做出该决定的人包括在对话中。如果他们不可用，无论如何都要进行对话，并对谁、什么以及为什么做出假设。然后与决策者分享这些假设。我向你保证，如果你做错了，他们会纠正你。讨论这些更正将开始正确的对话。

If it’s not your decision, or anyone on your team’s decision, to go ahead with this opportunity, then make sure you include those in the conversation who can make that decision. If they’re not available, have the conversation anyway, and make assumptions about who, what, and why. Then share those assumptions with decision makers. I promise you that they’ll correct you if you’ve got it wrong. Discussing those corrections will start the right conversation.

尽管我喜欢故事地图，但我不会使用地图来管理机会。这些机会通常是更大的块。关于这些大石头的讨论通常会朝着我们需要的细节推进，以便我们决定将它们带入更深层次的发现。

As much as I like story maps, I wouldn’t use a map to manage opportunities. Those opportunities are usually bigger chunks. And discussion about these big rocks usually drives toward the details we’ll need in order to decide about moving them into deeper discovery.

但故事地图擅长的一件事是为您提供了一种真正有效的方式，让您退后一步，查看您现在拥有的产品的全局。使用您今天为您的产品创建的地图来寻找机会，或者考虑您今天的产品背景下已经拥有的机会。

But one thing that story maps are great at is giving you a really effective way to step back and look at the big picture for the product you have now. Use a map you create for your product today to find opportunities, or to consider the opportunities you already have in the context of your product today.

尝试为现有产品构建一个简单的、非常高级的地图。这是一个“现在”地图，类似于您在第 5 章中构建的关于开始您的早晨的地图。（你确实建造了它，不是吗？）这些类型的地图已经以各种形式出现了一段时间。它们通常被称为旅程地图。要为您当前的产品体验制作一张地图，只需绘制用户在他们从事的主要活动中所经历的流程。使用此地图为您的机会提供背景信息。为此，将每个机会添加到地图主体中。使用不同颜色的便利贴或索引卡清楚地标出它们。您可能看到的是机会“热点”——用户流中的想法密度较高且用户可能会感到痛苦的地方。

Try building a simple, very high-level map of your existing product. This is a “now” map similar to the one you built in Chapter 5 about starting your morning. (You did build it, didn’t you?) These types of maps have been around in various forms for a while. They’re often called journey maps. To make one for your current product’s experience, just map the flow users take through the major activities they engage in. Use this map to give context to your opportunities. To do this, add each opportunity into the body of the map. Use a different color of sticky note or index card to clearly call them out. What you might see are opportunity “hot spots”—places in your users’ flow where there’s a higher density of ideas and likely pain from your users.

查看参与每项活动的用户，以及该活动的频率。影响关键用户参与的高频活动的机会很可能是您应该关注的机会——宜早不宜迟。

Look at the users engaged in each activity, and the frequency of that activity. Opportunities that affect high-frequency activities engaged in by critical users are likely opportunities you should be focusing on—sooner rather than later.

您可以使用同一张地图为用户今天抱怨的事情添加卡片。为了平衡事物，看看他们今天喜欢的产品部分，并添加这些乐趣。如果您发现用户有很多痛苦的地方，但您还没有发现任何机会，您可能应该这样做。

You can use this same map to add in cards for the things users complain about today. To balance things, look at the parts of the product that they love today, and add in those joys. If you find places where there’s lots of pain for users, but you haven’t yet identified any opportunities, you probably should.

旅程映射和概念生成

本·克罗瑟斯，Atlassian

Ben Crothers, Atlassian

鉴于我们提供超过 10 种不同的产品，我们必须确保我们设计、构建和改进这些产品的方式与我们的客户一起使用它们的方式相匹配，而不是一个一个地使用它们。作为发现产品如何以更好的方式协同工作的项目的一部分，我们组建了一个多学科团队来绘制整个端到端的客户体验，包括寻找、评估、购买和使用它们，以及获得帮助并添加更多产品和服务。

Given that we offer over 10 different products, we have to make sure that we design, build, and improve upon those products in ways that match how our customers use them together, not one by one. As part of a project to discover how the products could work together in a better way, we formed a multidisciplinary team to map the entire end-to-end customer experience in finding, evaluating, purchasing, and using them, as well as getting help and adding more products and services.

这是巨大的。为了帮助分解它，我们首先在高层次上描绘了经验，然后分成小组以扩展骨架旅程的每个部分。为此，我们首先用客户经历的时刻、行动和问题填满一堵墙，在我们走过的过程中用颜色编码，然后回过头来，添加痛点、机会和假设。

This was huge. To help break it down, we mapped the experience at a high level first, and then broke into subgroups to expand on each section of that skeleton journey. We did this by initially filling a wall with the moments, actions, and questions that customers go through, color-coding as we went, and then going back over it, adding pain points, opportunities, and assumptions.

通过能够追踪端到端的故事而不仅仅是基于功能的体验，我们获得了很多洞察力。例如，我们很快意识到，体验的某些部分——例如设置产品或获得帮助——并不是孤立于线性旅程的一部分，需要更多、更详细地满足。

We gained a lot of insight by being able to trace an end-to-end story rather than just a feature-based experience. We quickly realized, for example, that some parts of the experience—such as setting up products or getting help—weren’t isolated to one part of a linear journey, and needed to be catered for much more and in greater detail.

引入了各种其他利益相关者和团队来充实更详细的旅程，这些旅程都与高级骨架旅程中的各个点挂钩，以便我们尽可能多地捕获和验证现有知识。

Various other stakeholders and teams were brought in to flesh out more detailed journeys that were all pegged to various points along the high-level skeleton journey, so that we captured and validated as much existing knowledge as we could.

然后我们疯狂地想出尽可能多的概念来改进和重塑详细旅程的各个部分。所有的概念都被提炼并写在卡片上，并在旅途中以松散的顺序贴在墙上。

Then we went absolutely nuts coming up with as many concepts as we could to improve upon and reinvent various parts of the detailed journeys. All of the concepts were distilled and written up on cards, and stuck on the wall in loose order along the journey.

每个团队成员都解释了他或她的每个概念，之后我们根据概念的可行性、可行性和可取性，用粘点对概念的有效性进行了投票。

Each team member explained each of his or her concepts, after which we all voted on the concepts’ effectiveness with sticky dots, according to their feasibility, viability, and desirability.

然后，我们能够根据这些旅程和经过验证的概念，制定一个理想客户体验的整体跨产品​​愿景。一段 20 页的漫画也使旅程栩栩如生，将旅程以及所涉及的所有人物角色、场景和概念转变为一个故事板，从而更容易与整个组织沟通。这为今天继续进行的许多产品增强提供了信息。

We were then able to craft an overall cross-product vision of an ideal customer experience, based on these journeys and validated concepts. The journey was also brought to life with a 20-page comic, which transformed the journey—and all the personas, scenarios, and concepts involved—into a single storyboard that made it easier to communicate to the whole organization. This informs many product enhancements that continue today.

对我们来说真正引人注目的是，许多参与开发和改进这些增强功能的人现在也参与了生成概念的过程。尽管这个练习是在八个多月前完成的，但这种共同的概念和理解使现在的事情变得更加高效。

What’s really compelling for us is that many of those involved in developing and refining these enhancements now were also involved in generating the concepts to start with. Even though this exercise was done over eight months ago, that shared concepting and understanding makes things so much more efficient now.

具有挑战性的假设与排练重新映射

艾琳·贝尔沃尔特斯和亚伦·怀特

Erin Beierwaltes and Aaron White

1. 一张地图统领一切

1. One Map to Rule Them All

在客户拜访、访谈和探索之后，项目所有者得到了一张旅程图，他自信地相信它涵盖了为客户带来最佳结果的路径。许多团队照常营业。现在是时候与更多人分享并让它继续下去了。

After customer visits, interviews, and explorations, the project owner had a journey map that he confidently believed covered the path to the best outcome for the customer. Business as usual for many teams. Now it was time to share with more people and get it going.

2.质疑一切

2. Question Everything

但经过几次交谈后，我们开始质疑我们错过了什么。我们做了哪些可能产生比预期影响更大的简单假设？我们需要一种快速的方法来挑战我们的假设，找到漏洞，并在参与该项目的每个人之间建立共识。

But after a few conversations, we started to question what we had missed. What simple assumptions had we made that could have bigger than expected impact? We needed a quick way to challenge our assumptions, find holes, and build shared understanding among everyone who would be a part of the project.

3.设置场景

3. Set the Scene

我们召集了团队，分配了角色（有多个），并描述了自然会引导这些角色使用产品部分来测试我们假设的预期结果。我们没有编写分步说明。我们的方向：“简单来说，作为这个人，你想要完成这个目标。” 排演！

We gathered the team, assigned personas (there were multiple), and described the desired outcomes that would naturally guide those personas to use the part of the product that would test our assumptions. We did not write step-by-step instructions. Our direction: “Simply, as this person, you would like to accomplish this goal.” Rehearsal!

4.排练

4. Rehearsal

当演员们扮演他们的角色并试图达到他们描述的目标时，一些观察者扮演着沉默的观众的角色。

While the actors played their parts and tried to reach their described goals, a few observers played the part of the silent audience.

PO 观察了采取的路径，回答了几个问题，并避免引导任何人走上特定的路径。IxD 观察行为、评论和反应。

The PO observed what paths were taken, answering a few questions, and avoiding leading anyone down a particular path. The IxD observed behaviors, comments, and reactions.

5.重建地图

5. Rebuild the Map

我们没有展示原始地图，而是引导所有参与者构建一张描述他们如何实现目标的新地图，同时分享一些人如何采取不同的路径。

We didn’t show the original map, but instead walked all of the actors through building a new map that described how they accomplished their goals, sharing along the way how some took different paths.

6. 付出与收获

6. Pains and Gains

重建后，我们要求每个演员分享痛苦（挑战、沮丧或困惑的事情）和收获（他们认为圆滑、酷或直觉的事情）。谈话中充满了真正的新同理心、理解和兴奋感。

After the rebuild, we asked each actor to share pains (things that challenged, frustrated, or confused them) and gains (things they thought were slick, cool, or intuitive). A real sense of new empathy, understanding, and excitement filled the conversation.

7.观察

7. Observations

最后，轮到观众提问他们看到的有趣行为。我们惊讶于演员们不知道他们做了多少事情，但这给了我们一个窗口，让我们了解某人可能如何自然地尝试完成某事。

Finally, it was the audience’s turn to ask questions about interesting behaviors they had seen. We were amazed at how many things the actors were unaware they had done, but that gave us a window into how someone might naturally try to accomplish something.

8. 利润！！！

8. Profit!!!

仅仅 2.5 小时后，我们就以一种只有对话才有的方式对新解决方案的真实感受建立了共同的理解。演员们对他们所扮演的客户表达了真正的同理心，发现团队对什么是有效的以及可能需要进行更多实验的地方有了深刻的了解。

After only 2.5 hours, we had built shared understanding about the real feel of the new solution in a way only a conversation could have. Actors spoke with real empathy for the customers they played, and the discovery team had gained huge insights into what was working and where more experiments might be required.

如果你同意承担一切，你就不是在帮助任何人。积极地丢弃那些对创造你所希望的结果没有多大希望的机会。与业务利益相关者合作来做到这一点，以便他们可以帮助做出这些决定。

You’re not helping anyone if you agree to take on everything. Aggressively trash opportunities that don’t offer much hope of creating the outcomes you hope for. Work with business stakeholders to do this so they can help make those decisions.

如果您做出了前进的决定，那么就该卷起袖子开始工作了。这就是下一章的内容。

If you’ve made a go-forward decision, it’s time to roll up your sleeves and get to work. And that’s what the next chapter is about.

发现工作与构建可交付软件无关。这是关于学习。这是关于加深对我们可以建造什么的理解。这是关于提出和回答以下问题：

Discovery work isn’t about building shippable software. It’s about learning. It’s about building a deeper understanding of what we could build. It’s about asking and answering questions like:

它询问并开始回答所有这些关于开始您第一轮突破的机会的问题。您讨论的有关产品或功能的所有详细信息都将成为较小故事的标题。这些小故事中的每一个都可能导致更深入的讨论和更小的故事。

It’s asking and starting to answer all these questions about an opportunity that starts your first round of rock breaking. All the details about the product or feature you discuss become the titles of smaller stories. And each of those smaller stories can result in even deeper discussions, and still smaller stories.

所有这些发现讨论不仅会产生更多故事。请记住，故事讨论涉及创建许多其他简单模型来代表我们所理解的内容。我们将需要这些其他简单的模型来建立共同的理解。

All these discovery discussions don’t just result in more stories. Remember that story discussions involve creating lots of other simple models that represent what we understand. We’ll need these other simple models to build shared understanding.

如果我有一个大点子，或者是一个需要澄清的小点子，如果我们有一个值得构建的解决方案，我将按照讨论的这一进程从大的想法转移到我需要最好地理解的细节：

If I’ve got a big idea, or even a small one that needs some clarity, I follow this progression of discussions to move from the big idea to the details I’ll need to best understand if we’ve got a solution worth building:

2.了解客户和用户

2. Understand Customers and Users

使用关于客户的讨论和用户，以更深入地了解您的产品或功能所针对的人群，以及他们如何从中受益。让那些对用户有深刻理解的人，以及其他需要了解的人参与进来。

Use discussions about customers and users to gain more insight into the people your product or features are for, and how they benefit them. Involve those who have deep user understanding, and others who need to get it.

绘制简单的人物角色

Sketch simple personas

我喜欢与小型发现团队一起创建简单的角色草图建立对我的用户的共同理解。角色是您的目标用户的一个例子，它是根据事实，有时是您对用户的假设组合而成的。建立人物角色有助于我们通过用户的眼睛来看待软件。角色是方便的工具。

I like creating simple persona sketches with a small discovery team to build shared understanding of my users. A persona is an example of your target user assembled from the facts and sometimes the assumptions you have about your users. Building personas helps us look at the software through the eyes of our users. Personas are handy tools.

我与 Mano a Mano 的一个团队建立了这个简单的角色，这是一个非营利组织，通过从修建道路到支持教育和医疗保健等方方面面来帮助玻利维亚人民。我们今天的讨论是关于小型、精通互联网的捐助者——这类人可能没有很多钱，但希望他们必须捐赠的东西得到明智的使用。我们希望像 Chuck 这样的人能够在 Web 上找到 Mano a Mano，或者通过 Twitter 或 Facebook 听说它。

I built this simple persona with a group at Mano a Mano, a nonprofit group that helps people in Bolivia by doing everything from building roads to supporting education and healthcare. Our discussion this day was about small, Internet-savvy donors—the sort of people who may not have a huge amount of money, but want what they do have to give to be used wisely. We’d expect people like Chuck to find Mano a Mano on the Web or hear about it via Twitter or Facebook.

我们使用活动挂图纸作为一个小组一起创建了这个角色。这是一项快速、有趣的活动，有很多人大声喊叫并提供信息。

We created this persona together as a group using flipchart paper. It’s a fast, fun activity with lots of people shouting and contributing information.

现在，如果你是一位经验丰富的 UX 设计师，之前创建过角色，你现在可能会感到有点反胃。对于您阅读的其余部分，良好的角色是根据通过扎实的研究收集的良好数据构建的。担心这一点的用户体验人员可能会对团队成员大喊大叫并在活动挂图纸上涂鸦感到紧张。听起来不严谨。所以不要只是大声说出你的猜测。讨论你所知道的和你观察到的。讲故事。让对用户有第一手经验的人参与讨论。如果你做了很多研究，把它带入与你的讨论中。确定与您正在构建的机会最相关的细节并将其放入角色中。过滤掉噪音。完成后，就其中有多少只是猜测进行诚实的讨论。

Now, if you’re an experienced UX designer who’s created personas before, you may be feeling a little sick to your stomach right now. For the rest of you reading, good personas are built from good data gathered through solid research. UX people concerned about that might be nervous about team members just shouting stuff out and scribbling it on flipchart paper. It doesn’t sound rigorous. So don’t just shout your guesses. Discuss what you know and what you’ve observed. Tell stories. Involve people in the discussion who have firsthand experience with users. If you’ve done lots of research, bring it into the discussion with you. Identify the details most relevant to the opportunity you’re building and put those into the persona. Filter out the noise. When you’re done, have an honest discussion about how much of this is just a guess.

“我们已经创建了角色。它们是我们贴在墙上的精美文件。” 我听到很多。但要对自己诚实。大多数人没有读过它们，是吗？读过这些文章的人中有一半只是为了取笑他们。也许我很愤世嫉俗，但我看到了很多。

“We already have personas created. They’re beautiful documents we’ve posted on the wall.” I hear that a lot. But be honest with yourself. Most people haven’t read them, have they? And half of the people who did read them did so just to poke fun at them. Maybe I’m being cynical, but I see that a lot.

共同构建角色，协作。这样做是为了与团队就谁将构建产品建立共识。这样做是为了真正考虑人物角色最相关的方面。

Build personas together, collaboratively. Do this to build shared understanding with the team about who’ll build the product. Do this to really consider the most relevant aspects of the persona.

一起构建轻量级角色，以在团队内建立共同的理解和同理心。

Build lightweight personas together to build shared understanding and empathy within the team.

我为可能使用我们正在讨论的功能的每种类型的用户创建简单的角色。如果我行动迅速，我可能只列出使用该软件的不同类型的用户或角色，并记下有关它们的一些细节。还记得第 1 章中的加里吗？紧挨着 Gary 的一堆卡片中的一张就是这样的——用户列表和一些关于他们的相关信息。

I create simple personas for each type of user who might use the feature we’re discussing. If I’m moving fast, I may just list different types of users or roles using the software, and note a few details about them. Remember Gary in Chapter 1? One of the piles of cards right next to Gary was exactly that—a list of users and a few bullets of relevant information about them.

创建组织概况或 orgzonas

Create organizational profiles or orgzonas

如果您正在构建组织可能购买的产品（例如会计产品），请花时间列出不同类型的组织并记录有关它们的一些详细信息。这些是你的客户——手头有现金的人，他们需要从你的产品中获得一些价值。具有一些支持详细信息的组织类型通常称为组织概况。我的朋友 Lane Halley 首先向我介绍了如何创建示例组织配置文件，就像创建角色一样。为了好玩，她称它们为orgzonas。

If you’re building a product that organizations might buy—for example, an accounting product—take the time to list different types of organizations and record some details about them. These are your customers—the people with cash in hand who need to get some value from your product. An organization type with some supporting details is often called an organizational profile. My friend Lane Halley first introduced me to creating example organizational profiles much like you’d create a persona. For fun, she called them orgzonas.

映射用户今天的工作方式

Map how users work today

您可以更深入地了解用户在没有您的产品或使用当前产品时的工作方式。如果你在第 5 章中一起玩，你就构建了一个关于你今天做事方式的故事地图。按照您的用户今天的工作方式执行此操作将帮助您的发现团队真正了解他们正在解决的问题。

You can go one step deeper and map the way your users work today without your product, or with your current product. If you were playing along in Chapter 5, you built a story map about the way you do things today. Doing this for the way your users work today will help your discovery team really understand the problems they’re solving.

这些来自 Caplin Group 的 Duncan Brown 的照片展示了他们称之为叙事旅程地图的东西。这是一张地图，讲述了我在本书开始时使用的“现在和以后”模型的“现在”方面的故事。它没有描述我们的伟大解决方案；它描述了当今人们实现目标的方式——错误和所有。

These photos from Duncan Brown of the Caplin Group show something they call a narrative journey map. It’s a map that tells a story about the “now” side of the “now-and-later” model I started this book with. It doesn’t describe our great solution; it describes the way people reach their goals today—faults and all.

地图的主体包含事实、观察、痛苦和欢乐。当您映射您现在理解的内容时，您会看到“热点”——流程中存在很多问题的区域。您还会发现奖励——在一组步骤结束时让您的用户的努力值得的乐趣。您可以通过消除痛苦或放大快乐来构建有价值的产品。使用此地图作为集思广益解决方案的跳板，或验证您想到的解决方案是否确实解决了问题。

The body of the map contains facts, observations, pains, and joys. When you map what you understand now, you’ll see “hot spots”—areas in the flow where there are lots of problems. You’ll also find rewards—the joys at the end of a set of steps that make your users’ efforts worthwhile. You can build valuable products by taking away pains, or magnifying joys. Use this map as a springboard for brainstorming solutions, or for validating that the solution you have in mind really does solve problems.

3.设想你的解决方案

3. Envision Your Solution

到目前为止，您已经清楚地了解为什么要从业务角度构建它；您已经更深入地了解用户和客户，因此您了解他们的世界现在是什么样子。现在是想象未来的时候了——设想解决方案以及您的目标客户和用户将如何使用它。

By now you’ve framed to be clear on why you’re building this from a business perspective; you’ve dived deeper into users and customers so you know what their world looks like now. It’s time to imagine the future—to envision the solution and how your target customers and users will make use of it.

映射您的解决方案

Map your solution

这是故事地图的亮点，至少对我而言。我使用故事地图来想象我的用户使用我们正在构建的解决方案的生活。Gary 和 Globo.com 团队在前两章中都构建了这样的地图。正如我们在开头章节中讨论的那样，人们在你讲述的故事中采取的步骤形成了从左到右的流程。请记住第 4 章，这些是用户任务——从左到右阅读时可以讲述故事的简短动词短语。更细粒度的任务和其他细节在每个步骤下垂直堆叠。如果故事很长，则提取活动组以创建三层地图。

This is where story maps shine, at least for me. I use the story map to imagine the life of my users with the solution we’re building in place. Both Gary and the Globo.com team in the first two chapters built maps like this. As we discussed in the opening chapters, the steps people take in the story you tell form the left-to-right flow. Remember from Chapter 4 that those are user tasks—short verb phrases that, when read from left to right, tell the story. The finer-grained tasks and other details stack up vertically under each step. If it’s a long story, distill groups of activities to create a three-level map.

文字与图片

Words and pictures

您是否遇到过向开发人员描述产品创意的情况，当他说：“哦，这很简单。建造起来应该不会花很长时间。” 但是，当您真正着手并开始构建它时，您会意识到开发人员想象的东西比您想象的要简单得多。例如，您可能已经描述了一个在线销售您的东西的网站。您可能一直在想象像 eBay 或 Amazon Marketplace 这样的东西。但开发人员正在想象更像 Craigslist 的东西，这就是为什么你对这个估计感到满意。我在过去十年中了解到，仅靠文字是不够的。

Have you ever been in a situation where you describe a product idea to a developer, and are pleasantly surprised when he says, “Oh, that’s simple. It shouldn’t take long to build.” But, then when you really get going on it and start building it, you realize the developer was imagining something far simpler than you were. For example, you might have described a site to sell your stuff online. You might have been imagining something like eBay or Amazon Marketplace. But the developer was imagining something more like Craigslist, and that’s why you were pleased with the estimate. I’ve learned over the last decade that words alone just aren’t enough.

可视化您的用户界面以建立对解决方案的共同理解。

Visualize your user interface to build shared understanding of the solution.

如果你的团队中有 UX 设计师，现在是他们开始绘制草图的好时机。绘制单个屏幕并按照它们出现的顺序将它们张贴在地图上方。你最终会得到一个看起来像故事板的东西。

If you’ve got UX designers on your team, now’s a good time for them to start sketching. Sketch individual screens and post them above the map in the order they appear. You’ll end up with something that looks like a storyboard.

可视化整个体验

乔什·塞登 (Josh Seiden)，德米安·雷普奇 (Demian Repucci) 的作品

Josh Seiden, with artwork by Demian Repucci

有一天，我接到了罗伯特的电话，他是一家资金雄厚的大型教育初创公司最近聘请的设计经理。该公司正处于一个大项目的早期阶段，正在迅速招聘，并且在紧迫的期限内生产一个庞大的系统。只有一个问题：它无法弄清楚如何应对它所面临的巨大设计挑战。我能帮忙吗？

One day I received a call from Robert, a recently hired design manager at a large, well-funded education startup. The company was in the early stages of a big project, it was hiring rapidly, and it was on a tight deadline to produce a huge system. Just one problem: it was having trouble figuring out how to approach the enormous design challenge it was facing. Could I help?

几天后，当我到达办公室时，罗伯特——既自豪又不知所措——带我四处参观。该公司聘请了一家大型咨询公司来帮助其制定项目需求，并且该公司已经完成了大量工作。光线充足的阁楼办公室的每一面墙都贴满了棕色的牛皮纸，每张纸上依次贴满了索引卡和便利贴：需求，以用户故事的形式出现。成千上万的人。当罗伯特带我走过故事墙时，我注意到所有故事都是按功能模块组织的：文本编辑器墙、评分应用程序。和课程模块：一堵科学墙，一堵英语墙。我努力在脑海中构建一个系统图。

When I arrived in the office a few days later, Robert—both proud and overwhelmed—showed me around. The company had hired a large consulting firm to help it develop requirements for its project, and that firm had done an impressive amount of work. Every wall in the light-filled loft offices was covered with brown butcher paper, and each one of those sheets was in turn covered with index cards and Post-it notes: requirements, in the form of user stories. Thousands of them. As Robert walked me past the walls of stories, I noticed that all the stories were organized by functional module: a text editor wall, a grading application. And curriculum modules: a wall of science, a wall of English. I struggled to build a picture of the system in my mind.

罗伯特正在组建一个设计团队，同时也在努力细分问题。当我们讨论他的团队需要什么时，我们意识到我们可以使用故事地图来帮助组织成千上万的用户故事，从而帮助设计和开发团队从共同的愿景中运作。

Robert was in the process of building a design team, and also trying to segment the problem. As we talked through what his team needed, we realized we could use a story map to help organize the thousands of user stories in a way that would help the design and development teams operate from a shared vision.

巧合的是，几周前，我参加了一个故事板艺术家团队主持的研讨会。研讨会的目的是帮助企业家阐明他们的商业理念的愿景。这些艺术家快速工作，与企业家坐在一起，从他们的故事中汲取灵感，并将想法勾画成故事板——清晰地讲述每个故事的迷你漫画书。我决定将这种方法与故事映射结合起来，并打电话给在那次研讨会上给我留下深刻印象的一位艺术家 Demian Repucci。

Coincidentally, a few weeks earlier, I had sat in on a workshop facilitated by a team of storyboard artists. The goal of the workshop was to help entrepreneurs articulate a vision for their business ideas. Working quickly, these artists sat with the entrepreneurs, drawing their stories out of them and sketching out the ideas as storyboards—mini comic books that told each story with great clarity. I decided I wanted to combine this approach with story mapping, and called one of the artists who had impressed me in that workshop, Demian Repucci.

在接下来的几周里，德米安和我会见了罗伯特和他的团队，以及系统各个部分的产品经理。我们的重点是高级工作流程——系统中的主要用例。我们见面时，德米安在他的笔记本上画草图，我用索引卡和便利贴在会议室墙上勾勒出用例。会议结束后，Demian 会回到他的工作室绘制关键时刻的插图，而我使用 Omnigraffle 制作了我们在会议中起草的故事地图的清晰版本。

Over the next few weeks, Demian and I met with Robert and his team, as well as with the product managers of the various pieces of the system. Our focus was on high-level workflow—the major use cases in the system. As we met, Demian sketched in his notebook and I used index cards and Post-it notes to outline the use cases on the conference room walls. After the meetings, Demian would return to his studio to illustrate key moments, and I used Omnigraffle to produce clean versions of the story maps that we had drafted in our meetings.

与罗伯特一起，我们认为我们可以提供的最有价值的东西是团队的组织结构，所以我们制作了一系列海报，可以打印在 11×17 的纸上并贴在墙上，形成团队的“脊柱”故事地图。然后团队可以独立地使用它以新的方式组织他们的用户故事。与不适合迭代开发的以模块为中心的视图不同，我们现在有一个以使用为中心的方法，可以切入跨模块发布。

With Robert, we decided that the most valuable thing we could deliver was the organizing structure for the team, so we produced a series of posters that could be printed on 11×17 paper and taped to the walls to form the “spine” of the story map. The teams could then use that independently to organize their user stories in a new way. Instead of a module-centric view that doesn’t lend itself to iterative development, we now had a usage-centric approach that could be sliced into cross-module releases.

设想涉及整个团队的用户体验的一种方法是设计工作室方法。设计工作室是一种快速、简单且协作的方式，可以让一大群人参与深思熟虑的构思，这是一个华而不实的词，可以提出很多可能的想法。您很快就会了解到，没有一个人拥有最好的想法。相反，最好的想法通常是几个人的想法以及更多讨论的结合。设计工作室（和简单的想法，就此而言）与包括我在内的大多数人经常做的事情相反：接受第一个看起来可行的想法。我第一次看到Jeff White 和 Jim Unger描述的 Design Studio 时想知道为什么我没有一直这样做。我已经完成了这些涉及开发团队、利益相关者，甚至客户和最终用户的工作。

One approach to envisioning the user experience that involves the whole team is a Design Studio approach. A Design Studio is a fast, simple, and collaborative way to involve a large group in deliberate ideation, which is a flashy word for coming up with lots of possible ideas. What you’ll quickly learn is that no single person has the best ideas. Rather, the best ideas are often a combination of several people’s ideas along with more discussion to build on them. A Design Studio (and simple ideation, for that matter) is the opposite of what most folks, including me, often do: go with the first idea that seems like it’ll work. I first saw Design Studio described by Jeff White and Jim Unger and wondered why I hadn’t always been doing it. I’ve done these involving development teams, stakeholders, and even customers and end users.

无论您使用什么方法，结合想法，完善它们，并对软件的外观达成共识。

Whatever approach you use, combine ideas, refine them, and come to a shared understanding of what the software could look like.

这里发生的一件令人不安的事情是可视化您的解决方案将帮助您捕捉到您在地图中错过的东西。您会发现您可能需要添加、更改或重新组织地图以支持您的可视化内容。别担心：这是件好事。

An uncomfortable thing that happens here is that visualizing your solution will help you catch things you’ve missed in the map. You’ll find you may need to add, change, or reorganize the map to support what you’ve visualized. Don’t worry: that’s a good thing.

设计工作室食谱

设计工作室是一种快速、协作的构思方法。有很多方法可以正确地做到这一点，但这是我的简单方法：

A Design Studio is a quick, collaborative approach to ideation. There are lots of ways to do this right, but here’s my simple recipe:

1. 邀请一群人，他们的意见和想法是您喜欢的，他们的支持和理解是您构建产品所需要的。八到十二个人是一个不错的数字。
2. Invite a group of people whose opinions and ideas you’d like, and whose buy-in and understanding you’ll need to build the product. Eight to twelve people is a good number.
3. 描述您正在解决的问题。查看您为构建机会所做的工作。查看角色和任何描述人们当今工作方式的“现在”地图。查看您可能已经开始的任何解决方案图，但要注意不要说太多。如果他们将自己的想法寄托在你的身上，你可能会错过他们的一些好主意。
4. Describe the problem you’re solving. Review the work you did to frame the opportunity. Review personas and any “now” maps that describe how people work today. Review any solution maps you may have started, but be wary of saying too much. If they anchor their ideas on yours, you may be missing out on some of their great ideas.
5. 可选择分享示例和灵感。讨论并展示其他类似的产品，这些都是很好的例子。讨论并展示可能不同但具有可以利用的好创意的产品。
6. Optionally share examples and inspiration. Discuss and show other similar products that are good examples. Discuss and show products that may not be the same, but that have good ideas in them that could be leveraged.
7. 大家素描！给每个人纸、笔，也许还有一些素描模板，以及固定的时间。我看短则 5 分钟，多则 60 分钟。我喜欢用 15 分钟。
8. Everyone sketch! Give everyone paper, pens, maybe some sketching templates, and a fixed amount of time. I see as little as 5 minutes, and as much as 60. I like using 15 minutes.
9. 在小组中，分享想法。我喜欢以 4 人一组的方式进行，所以如果您有 12 个人，请将其分成三组，每组 4 人。逐人分享您的最佳想法。团队成员提供反馈。指导参与者就解决方案解决问题的效果提供反馈，而不是他们有多喜欢这些解决方案。指导他们以他人的想法为基础。在固定的时间范围内逐人继续——30 分钟通常对我来说有效。
10. In small groups, share ideas. I like doing this in groups of 4, so if you had 12 people, break that into three groups of 4. Person-by-person, share your best idea. Team members give feedback. Coach participants to give feedback on how well the solutions address the problem, not on how much they like them. Coach them to build on others’ ideas. Continue person-by-person for a fixed time-box—30 minutes usually works for me.
11. 要求每个小组将他们最好的想法整合到一个草拟的解决方案中。这是最难的部分。为此需要 15-30 分钟。
12. Ask each group to consolidate their best ideas into a single sketched solution. This is the hardest part. Take 15–30 minutes for this.
13. 要求每个小组与整个小组分享他们最好的、综合的想法。讨论这些。
14. Ask each group to share their best, consolidated ideas with the whole group. Discuss these.
15. 谢谢大家，收集草图和想法。您、您的 UX 设计师或您的核心发现团队将需要利用它们来创建最终的、最佳的、整合的 UI 草图。请记住，用我的朋友 Leisa Reichelt 的话来说，“社区设计不是委员会设计。” 这里会有很多好的竞争想法，必须有人做出艰难的决定。
16. Thank everyone, and gather up the sketches and ideas. You, your UX designer, or your core discovery team will need to leverage them to create a final, best, consolidated UI sketch. Remember, in the words of my friend Leisa Reichelt, “design by community is not design by committee.” You’ll have lots of good competing ideas here, and someone’s got to make the tough call.

验证完整性

Validate completeness

我们的头脑擅长的事情之一就是填写细节。例如，当我们看到漫画的两帧画面时，我们的大脑会填充其间发生的事情。对于漫画书、小说和电影来说，这是一个很酷的技巧。但是，在思考软件的功能时，我们通常会想象有趣的功能，而忽略其间发生的必要内容。过度扩展电影隐喻，有点像只谈论汽车追逐和枪战，而忽略了解释为什么所有这些动作发生的故事。

One of the things our heads are good at is filling in details. For example, when we see two frames of a comic strip, our brains fill in what happened in between. This is a cool trick for comic books, novels, and movies. But, when thinking through what software does, we’ll often imagine the interesting features while neglecting the necessary stuff that happens in between. Overextending the movie metaphor, it’s sort of like talking only about the car chases and gunfights, and leaving out the story that explains why all that action took place.

使用地图讲述用户故事的全部内容可以帮助您记住谈论中间的那些关键细节。您通常会发现，您所考虑的非常酷的功能需要在故事的早期由用户进行一些设置，并导致在故事的后期对报告和通知进行一些更改。您的新功能创意甚至可能会对其他人产生影响。例如，管理员可能需要管理安全问题，或者经理可能希望监督其员工如何使用该功能。

Telling the full breadth of your users’ stories using a map helps you remember to talk about those critical details in between. You’ll usually see that the really cool feature you were thinking of needed some setting up by the user early in the story, and resulted in some changes to reports and notifications later in the story. There may even be consequences for others of your new feature idea. For example, administrators may need to manage security concerns, or managers may like oversight on how the feature is being used by their staff.

验证工程问题

Validate engineering concerns

回到电影制作的比喻，如果你打算继续制作这部电影，你需要开始考虑如何以及在哪里拍摄它。您需要考虑所需的特殊效果种类。在某些时候，您需要比故事更深入，并考虑制作电影的技术细节。

Back to the filmmaking metaphor, if you are going to move on to make this movie, you’ll need to start thinking about how and where you’ll film it. You’ll need to consider the kinds of special effects you’ll need. At some point you’ll need to go deeper than the story and consider the technical details of making your movie.

软件的故事地图有助于进行与制作电影时相同的讨论。在取得进展之前，与工程师和架构师讨论您的解决方案图。纵观大局有助于他们思考更大的工程限制，这些限制可能会导致解决方案存在无可救药的缺陷。他们可以提前警告您，您的解决方案可能听起来很酷，但考虑到您当前的体系结构和时间预算，构建它是不可行的。他们通常可以建议替代方法来为您的用户提供同等体验，但构建起来更具成本效益。

A story map of your software is helpful for the same kind of discussion you’d have making a movie. Discuss your solution map with engineers and architects before getting too far along. Seeing the big picture helps them think through bigger engineering constraints that could result in hopelessly flawed solutions. They can give you early warning that your solution may sound cool, but it’s not feasible to build given your current architecture and time budget. They can often suggest alternative ways of doing things that’ll give your users an equivalent experience, but be more cost effective to build.

这些大型保险公司的工程师已经在这张地图前讨论了很长时间。在他们的谈话过程中，他们在这张关于他们产品的大地图中发现了一个障碍。他们产品中的业务规则引擎需要改变。看到大局帮助他们形象化并直接面对复杂性。他们将利用这些知识来讨论他们可以计划及早采取哪些措施来帮助降低风险。

These engineers for a large insurance company have been talking in front of this map for a long time. During the course of their conversation, they’ve found a snag in this big map about their product. The business rules engine in their product needs to change. Seeing the big picture helped them visualize and directly confront the complexity. They’ll use that knowledge to talk about what they can plan to do early to help mitigate risks.

播放“关于什么”

Play “What-About”

您已经从用户的角度设想了解决方案，并将用户体验形象化。花点时间讨论一下用户界面下面发生了什么。谈论严格的业务规则、复杂的数据验证以及您需要连接的讨厌的后端系统或服务。将故事添加到命名这些部分的地图中。或者确保你对你的故事做笔记。

You’ve imagined the solution from a user’s perspective, and visualized the user experience. Take some time to discuss what’s going on underneath the user interface. Talk about tough business rules, complex data validation, and nasty backend systems or services you’ll need to connect with. Add stories into the map that name these parts. Or make sure you make notes on the stories you have.

现在也是与许多其他人一起回顾你所拥有的东西的好时机。分享你和你的小组的想法。我保证你会遇到问很多问题的人，这些问题以“关于……怎么样”开头。我喜欢这些人，尽管当他们就在我面前时并不总是这样。但我喜欢他们帮助我在我后来偶然发现困难的事情之前思考困难的事情，那时学习起来会更加痛苦。

It’s a good time to review what you’ve got with lots of other people as well. Share what you and your group have come up with. I promise you’ll get people who ask lots of questions that start with “What about…” I love these people, although not always when they’re right in front of me. But I love that they’re helping me think of the tough stuff before I stumble on it later, when it’ll be even more painful to learn.

电影隐喻在这里对我来说真的很管用。如果我要拍一部电影，我会想要一个剧本和一个故事板——帮助我想象这部电影的关键场景的草图。如果我正在投资一部电影，我至少需要看到它才能清楚地了解编剧和导演的设想。如果我现在喜欢这部电影，我将需要更多地了解它的成本以及制作的可行性。

The movie metaphor really works for me here. If I were going to make a movie, I’d want a screenplay and a storyboard—the sketches of key scenes that help me imagine the movie. If I were investing in a movie, I’d need to see at least that to get a clear picture of what the writers and directors were envisioning. If I liked the movie at this point, I’m going to need to learn a bit more about how much it costs, and how feasible it is to produce.

我希望他们能使用这些草图来更深入地思考这部电影。我想知道他们考虑过我们需要拍摄多少个地点以及它们的外观。我想知道他们考虑过我们需要什么样的布景、道具和特效。作为重要的好莱坞投资者，我需要剧本、故事板和许多其他细节来支持粗略的计划和估算。我们需要这个，这样我们才能为制作这部电影设定预算和时间表。

I’d hope they’d use those sketches to think more deeply about the movie. I’d want to know that they’d considered how many locations we’d need to film in and what they looked like. I’d want to know that they’d considered what kinds of sets, props, and special effects we’d need. As the important Hollywood investor, I’d need the screenplay, the storyboard, and lots of other details that supported a rough plan and an estimate. We’d need this so we could set a budget and a timeline for making the movie.

这是您开始构建解决方案之前需要的东西。

This is the sort of stuff you need before you start building your solution.

想法、例子和旅程

大卫·哈斯曼，DevJam

David Hussman, DevJam

许多人将发现过程过度复杂化，但它可以非常简单并且仍然很强大。抛开“需求”的神话般的确定性，花点时间以示例和旅程为指导来探索想法的发现。

Many people overcomplicate the discovery process, but it can be quite simple and still remain powerful. Step past the mythical certainty of “requirements,” and take a moment to explore the discovery of ideas using examples and journeys as your guide.

• 使用以下简单指南： 1) 建议探索一个产品创意，2) 选择您认为将从该创意中受益的人，3) 使用产品创意创建他们的示例集合，以及 4) 使用这些示例创建一个地图和您认为他们应该进行的旅程。请记住，作为产品创造者，您肩负着创造有意义的体验的责任，而不仅仅是创造更多功能。
• Use the following simple guide: 1) suggest a product idea to explore, 2) select people you think will benefit from the idea, 3) create a collection of examples of them using the product idea, and 4) use those examples to create a map and the journeys you think they should take. Remember that as the product creator, you’ve taken on the onus of creating meaningful experiences and not just more features.
• 想法不需要很出色。当然，你想要一个伟大的产品，但通常被认为是绝妙的想法不会成功，而其他的——不那么闪耀的——在你探索它们在某人试图完成某事的背景下的用途时会变得光彩夺目意义。
• Ideas do not need to be brilliant. Of course you want a great product, but often ideas deemed to be brilliant don’t pan out, while others—which don’t shine so brightly—grow in brilliance as you explore their use in the context of someone trying to accomplish something of meaning.
• 选择乘客不是火箭科学。不要使选择过于复杂。如果您不确定从哪里开始，只需列出您认为将从您的想法中受益的人。以人性化的方式构思它们，使它们栩栩如生，并在产品开发社区的口中和思想中保持活力。在你和他们一起工作之后，选择一个人一起工作，不要担心这个人是否合适。准备好从探索中学习，避免担心你的选择是否正确——它可能不正确。
• Selecting passengers is not rocket science. Don’t overcomplicate the selection. If you are unsure where to start, simply make a list of the people you think will benefit from your ideas. Frame them in a humane way so they come to life and stay alive in the mouths and minds of the product development community. After you have worked them a bit, select someone to work with and don’t worry if it’s the right person. Be ready to learn from exploring, and avoid worrying whether or not your selection is right—it probably is not.
• 创建各种示例列表。这是许多人失去控制并意外陷入复杂性的地方。从一个简单或明显的例子开始；越具体越好。然后想出一个复杂的例子，不要害怕设置高标准。你正在创造一系列的限制，你不是在向世界上的任何人承诺。再次，使复杂的例子具体化。如果你正在寻找你应该有多具体，并且你很勇敢，用测试代替工作示例，你将离自动验证工具更近一步。
• Create a varied list of examples. This is where many people lose control and accidentally stumble into complexity. Start with a simple or obvious example; the more concrete, the better. Then come up with a complex example, and don’t fear setting the bar high. You are creating a range of constraints, you are not promising anyone the world. Again, make the complex example specific. If you’re looking for how specific you should be, and you are courageous, replace the work example with a test, and you’ll be one step closer to an automated validation vehicle.
• 添加一些介于明显和复杂之间的示例，然后从简单的开始。以简单的例子为指导，讲述乘客的故事。将它告诉其他人，让那个人帮助您捕捉旅途中的故事。您的用户开始时在哪里？是什么触发他们参与？他们具体是做什么的？它是如何结束的？使用各种示例为您的乘客探索各种旅程。
• Add a handful more examples that fit between the obvious and the complex, and then start simple. Tell the story of the passenger using the simple example as your guide. Tell it to someone else, and have that person help you capture the stories on the journey. Where are your users when they start? What triggers them to engage? What do they do, specifically? How does it end? Use the various examples to explore the various journeys for your passengers.
• 选择有助于您学习的旅程。担心从哪里开始是另一个复杂的问题。浏览地图，选择您认为最能帮助您了解您的受众及其需求的旅程。同样，如果您担心自己没有做出正确的选择，那么您可能是对的。最好的发现方式和最好的学习投资是选择一些旅程，构建它们，然后观察人们使用它们——亲自或通过实时分析。
• Choose the journeys that will help you learn. Worrying about where to start is yet another complexity well. Walk the map, selecting journeys that you think will teach you the most about your audience and their needs. Again, if you’re worried that you are not making the right selection, you may be right. The best way to find out, and the best investment in learning, is to select a few journeys, build them, and watch people use them—in person or via real-time analytics.
• 避免产品傲慢的陷阱。你认为人们需要的东西和他们真正需要的东西之间的区别是产品傲慢的境界。使用此处列出的过程，您可以通过一次构建和验证一个旅程来更快地在上下文中学习。
• Avoid the trap of product arrogance. The difference between what you think people need and what they really need is the realm of product arrogance. Using the process laid out here, you can more quickly get to learning in context by building and validating one journey at a time.

还不庆祝

Don’t celebrate yet

通过发现流程中的这一步，您应该已经开始将您的解决方案的各个部分描述为单独的故事。每件作品都是重大机遇的一部分。如果您像我一样，已经使用故事地图来组织所有部分。如果你比我聪明，你会发明一种更好的方法来组织所有的部分——如果是这样的话，你应该马上联系我。如果你有点昏暗，你就会有一大堆。甚至更糟的是，有人可能编写了一份冗长的需求文档，混淆了您所学的一切。请不要那样做。

By this step in the discovery flow, you should have begun to describe your solution’s parts as individual stories. Each piece is a part of the big opportunity. If you’re like me, you’ve used a story map to organize all the parts. If you’re smarter than me, you’ll have invented an even better way to organize all the parts—and if that’s the case, you should get in touch right away. If you’re a little dim, you’ll just have a big pile. Or even worse, someone may have written a big long requirements document that obfuscates all you’ve learned. Please don’t do that.

无论你在这里结束了什么，你都处于许多人庆祝的时刻，因为他们已经“完成了要求”。不要成为那些人。您还有最后也是最重要的一步要做。

Whatever you end up with here, you’re at the point where lots of people celebrate because they’ve “finished the requirements.” Don’t be those people. You’ve got a last and most important step to do.

4. 最小化和计划

4. Minimize and Plan

您已经设想了一个带有文字和图片的解决方案，在这一点上，您的团队可能会感到非常自豪。但发现的一大问题当我们齐心协力找出一个绝妙的解决方案时，就会发生这种情况，其中包含我们都喜欢的许多花里胡哨的东西。

You’ve envisioned a solution with words and pictures, at this point, your team may be feeling pretty proud. But one of the big problems with discovery happens when we all work together to identify a fabulous solution with lots of bells and whistles that we all love.

我知道你在想什么。为什么那会是个问题？

I know what you’re thinking. Why would that be a problem?

当我们专注于让每个人都开心，而同时未能专注于小的、具体的目标结果时，问题通常就会出现。结果是一个比它需要的大得多的解决方案。

The problem usually comes in when we focus on making everyone happy, and at the same time fail to focus on small, specific target outcomes. The result is a solution that’s much bigger than it needs to be.

请记住，我们的目标是最大限度地减少我们构建的数量（我们的输出）并最大化我们从中获得的收益（结果和影响）。你的机会将分成许多可能的小故事。我们当然不会全部建造它们。那不会最小化输出，对吗？

Remember, our goal is to minimize the amount we build (our output) and maximize the benefit we get from doing it (the outcomes and impact). Your opportunity will break into lots of possible smaller stories. We certainly wouldn’t build them all. That wouldn’t be minimizing output, would it?

如果你没有砍掉比保留更多的想法，你可能没有正确地进行发现工作。

If you’re not cutting away more ideas than you keep, you’re probably not doing discovery work right.

总是有太多

There’s always too much

对不起，但是有。如果您长期从事软件开发，您可能已经知道这一点。我已经尝试了很多年，实际上是十多年，假装这不是真的。我已经放弃了。你也应该。但别担心：您有一些工具可以帮助您确定在给定的时间和人员的情况下构建的可行性。

I’m sorry, but there is. If you’ve been involved with software development for any length of time, you likely already know this. I’ve tried for many years, over a decade really, to pretend it’s not true. I’ve given up on that. You should, too. But don’t worry: you’ve got some tools that’ll help you identify something feasible to build given the time and people you have.

在第 3 章，您了解到 Globo.com 使用地图来应对艰难的最后期限的方法。该公司专注于那个最后期限，接受它，并确定了一个能让它成功的结果。然后它把积压的订单切成薄片；也就是说，它删除了实现该结果所不需要的所有故事。这是它的最小可行解假设。这不仅仅是一个糟糕的、半生不熟的大创意版本——它是一个真正伟大的版本，非常专注于在巴西选举中取得成功。Globo 的人相信这对他们的业务、广告商、电视网络和用户都有价值。他们考虑了所有用户，并且非常有信心他们有一个可用的解决方案。通过切割他们的地图，他们找到了一个在给定时间和团队的情况下可行的解决方案。

In Chapter 3, you read about Globo.com’s approach to using a map to confront a tough deadline. The company focused on that deadline, embraced it, and identified an outcome that would let it be successful. Then it sliced up its backlog; that is, it cut away all the stories that weren’t necessary for it to reach that outcome. This was its minimal viable solution hypothesis. And it wasn’t just a crappy, half-baked version of the big idea—it was a really great version that was sharply focused on being successful for the Brazilian elections. The Globo folks believed it would be valuable to their business, their advertisers, TV networks, and their users. They’d thought about all their users, and were pretty confident they had a usable solution. And by slicing their map, they’d found a solution that was feasible to build given the time and teams they had. That intersection of valuable, usable, and feasible for a specific target set of customers, users, and uses is a viable solution.

可行意味着特定业务战略、目标客户和用户的成功。

Viable means successful for a specific business strategy, target customers, and users.

我们也可以考虑从第一个可行版本到第二个和第三个可行版本。但我们知道，一旦第一个版本上线，世界就会改变，这很好。但这也意味着我们需要根据我们创造的新世界重新考虑未来的发布。

We can think past that first viable release to second and third viable releases, too. But we know that once that first release goes live, the world will have changed, and that’s good. But it’ll also mean we’ll need to rethink the future releases in light of the new world we’ve created.

优先排序的秘诀

The secret to prioritization

靠近一点，因为我要低声说这个。

Step in close, because I’m going to whisper this.

知道这一点的人并不多——或者至少他们表现得好像不知道。也许他们只是在装傻，让人们失望。

Not many people know this—or at least they behave like they don’t. Maybe they’re just playing dumb to throw people off.

如果你一直在敏捷中徘徊开发一段时间后，您可能听说过“按业务价值确定故事的优先级”这一短语。该陈述在某种程度上是正确的，但是在您看到“业务价值”一词的地方，您应该用一些具体的内容来填充它。这是您和您的发现团队需要具体说明什么是有价值的地方。

If you’ve hung around in Agile development for a while you might have heard the phrase “prioritize stories by business value.” The statement is true, sort of, but where you see the words “business value,” you’re supposed to fill that in with something specific. This is where you and your discovery team need to say specifically what is of value.

让我们再看看疯狂咪咪。加里需要在资金用完之前尽快找到一种在特定市场上可行的产品。对 Gary 而言，可行意味着他拥有喜欢该产品并愿意为之付费的观众。他可以开始增加产品的受众，并因此增加他所赚取的收入。

Let’s look at Mad Mimi again. Gary needed to find a product that would be viable in a specific market soon, before he ran out of money. Viable for Gary meant he had an audience that liked the product and would pay for it. And he could begin to grow the product’s audience and the revenue he earned as a consequence.

正是这一业务目标与财务限制相结合，要求 Gary 专注于他支持的特定用户和用户活动。Gary 仍然对创建以 Mimi 命名的“音乐行业营销界面”寄予厚望。但他决定首先关注乐队经理，通过直接电子邮件营销向他的粉丝宣传他的乐队。在他这样做之后，他需要关注的具体功能变得清晰起来。

It’s that business goal combined with financial constraints that required Gary to focus on specific users and user activities he’d support. Gary still had high hopes of creating the “music industry marketing interface” that gave Mimi her name. But he decided to focus first on the band manager promoting his band using direct email marketing to his fans. After he did that, the specific functionality he needed to focus on became clear.

如果你刚才仔细听，你就会发现优先顺序的秘密。

If you were listening closely just now, you caught the secret to prioritization.

特定的业务成果推动关注特定用户、他们的目标以及他们将使用您的产品参与的活动。专注于这些活动会推动专注于用户成功所需的特定特性和功能。

Specific business outcomes drive focus on specific users, their goals, and the activities they’ll engage in with your product. Focus on those activities drives focus on the specific features and functionality users will need to be successful.

对于 Mad Mimi，Gary 深思熟虑地决定专注于取悦乐队经理来宣传他们的乐队。这就是他选择关注的具体价值。他没有使用模棱两可的术语“商业价值”。他用对他有价值的东西填补了空白。

For Mad Mimi, Gary made a deliberate decision to focus on delighting band managers promoting their bands. That’s the specific value he chose to focus on. He didn’t use that ambiguous term “business value.” He filled in that blank with what was of value to him.

大多数人犯的优先级错误是尝试首先确定功能的优先级。

The prioritization error that most people make is to try to prioritize features first.

在确定功能的优先级之前，先确定特定业务目标、客户和用户的优先级，然后是他们的目标。

Prioritize specific business goals, customers, and users, and then their goals, before prioritizing features.

下次当你发现有人问哪个功能更优先而不讨论业务目标、目标用户和他们的使用时，这就是你开始提问的提示。尽量不要表现得太自鸣得意。不是每个人都知道这个秘密。

The next time you catch someone asking which feature is higher priority without discussing business goals, target users, and their use, that’s your cue to start asking questions. Try not to act too smug. Not everyone knows this secret.

在发现过程中，您和您的团队可以创建很多活动和工件。这是一个快速表格，可以为您提供一些您可以做的事情的基本起点。不要做所有这些事情，因为它可能太多了。并且不要只做这些事情，因为可能有适合您的技能和背景的等效甚至更好的实践。但绝对不要只是坐在一个房间里写很多故事。那太疯狂了。

There are a lot of activities and artifacts you and your team can create during discovery. Here’s a quick table that’ll give you some basic starting points for the kinds of things you could do. Don’t do all these things, because it’s likely too much. And don’t do just these things, because there are likely equivalent or even better practices that suit your skills and context. But definitely don’t just sit in a room and write lots of stories. That’d be crazy.

您还记得在一个没有人完全了解大局的软件项目中工作吗？您还记得有一次团队在开发过程中了解到他们没有计划的大量工作吗？通常，当这种事情过去发生在我身上时，我们会发现在我们团队中的所有人以及与我们合作的外部人员之间，我们都有答案。如果我们刚刚达成共识，我们本可以很容易地预见到我们遇到的问题。

Do you recall working on a software project where no one quite understood the big picture? Do you recall a time when the team learned halfway through development about a big chunk of work they hadn’t planned on? Often, when this stuff has happened to me in the past, we’ll find that between all of us in the team, and the outside people we collaborate with, we had the answers. We could have easily foreseen problems we ran into if we’d have just gotten on the same page.

第 1 章中 Gary 的故事有点关于 Gary 和他的交付团队对全局的理解不一致。即使是加里——那个在脑海中掌握产品愿景的人——也没有清楚地了解他的产品的规模和复杂性。将他的产品想象成一堆简单的模型帮助他和他所依赖的每个人在他们的脑海中形成了同样的大局。

Gary’s story in Chapter 1 is a bit about Gary and his delivery team not having shared understanding of the big picture. Even Gary—the guy who held the vision of the product in his head—didn’t have a clear understanding of the size and complexity of his product. Visualizing his product as a bunch of simple models helped him and everyone he was relying on get the same big picture in their minds.

对于你构建的某些东西，让每个人都了解你的客户和用户是谁以及你为他们考虑的解决方案的大局就足够了。但我需要警告你，你对你正在建造的东西的假设可能是错误的。别担心：我想告诉您一些策略，它们确实可以让发现实践发挥作用。这就是下一章的内容。

For some things you build, it may be enough to just get everyone on the same page about who your customers and users are, and the big picture of the solution you have in mind for them. But I need to warn you, your hypothesis about what you’re building is probably wrong. Don’t worry: there are a couple of strategies I want to tell you about that really make discovery practice work. And that’s what the next chapter is about.

我和下一个相信我的伟大想法会成功的人一样内疚。事实上，过去我发布了很多我认为会非常成功的解决方案，但事实并非如此。它们也不是令人沮丧的失败——它们只是没有产生太大的影响。发生这种情况时，我和我的公司学会了换个角度看。不仅仅是我。我们都认为我们添加的功能很有价值。但最后我们添加了一些人使用的功能，但大多数人没有，我们知道我们最终会支持我们产品的生命周期。

I’m as guilty as the next guy in believing my great ideas will be successful. The truth is that in the past I released lots of solutions I thought would be wildly successful, but they just weren’t. They weren’t dismal failures, either—they just didn’t make much of a difference. When this happened I, and my company, learned to look the other way. It wasn’t just me. We all thought the features we were adding would be valuable. But in the end we’d added a feature a few people used, but most didn’t, and we knew we’d end up supporting for the life of our product.

我的信念不是基于任何正式的科学研究，而是基于我自己的失败以及我在与其他公司合作时所观察到的，即我们所构建的东西很少是成功的或具有我们希望的真正影响。我估计最多 20%。然后，我们所做的另外 20% 的事情是真正的失败——导致负面影响的解决方案。我见过很多组织发布了一个新的、更好的网站版本，但发现销量下降，或者发布了一个新版本的产品，客户试用后要求退回旧版本。这就是我所说的失败。

My belief, not rooted in any formal scientific research or studies, but just in my own failures and what I observe working with other companies, is that very little of what we build is successful or has the real impact we hope for. I figure around 20 percent max. Then there is another 20 percent of things we do that are genuine failures—solutions that result in a negative impact. I’ve seen a variety of organizations that release a new, better version of their website and see sales decrease, or release a new version of their product that customers try and then demand the old version back. That’s the kind of failure I’m talking about.

但这是中间的 60%，无论是给予还是接受，这既不是成功也不是失败，这才是大问题。这是我们花费宝贵的开发资金创造的东西，最终希望我们没有。

But it’s that 60 percent in the middle, give or take, that is neither success nor failure that’s the big problem. This is the stuff that we spend valuable development money creating, and in the end wish we hadn’t.

Standish Group 发表在历史性“混沌”报告中的研究解释说，64% 到 75% 的功能很少或从未使用过。^{[ 14 ]}而且，根据您查看的来源，75-90% 的软件初创公司都失败了。^{[ 15 ]}

Research from the Standish Group published in historic “Chaos” reports explains that between 64 and 75 percent of features are rarely or never used.^[14] And, depending on the source you look at, 75–90 percent of all software startups fail.^[15]

当你想到这一切时，这一切都非常令人失望。难怪只是假装它在工作是大多数组织的选择策略。

All this is pretty disappointing when you think about it. No wonder just pretending it’s working is the strategy of choice for most organizations.

在过去糟糕的日子里，我曾经有点像这样工作。我想出了一个好主意，或者实际上是其他人（例如我的首席执行官或重要客户）将他们的好主意交给了我。我会开始努力理解它并充实它。然后我和我的团队会建造它。它总是花费我们预期的两倍时间，但这是一个需要在后面的章节中处理的问题。我们会完成的。我们会发货。我们会庆祝。有时我们庆祝，然后发货。但无论哪种方式，我们都完成了。

In the bad old days, I used to work a bit like this. I’d come up with a great idea, or in reality, someone else like my CEO or a key customer handed me their great idea. I’d get to work making sense of it and fleshing it out. Then my team and I would build it. It always took twice as long as we expected, but that’s a problem to deal with in later chapters. We’d finish. We’d ship. We’d celebrate. Sometimes we celebrated, then shipped. But either way, we were done.

但后来事情真的开始发生了。通常发生的事情是人们抱怨我们提供的东西没有按照他们想要的方式工作。有时他们根本没有抱怨（我们后来发现这是没有人真正使用它的副作用）。然后我们会花很多时间假装我们成功了。对于你们中的一些人来说，这可能描述了你们公司今天的运作方式。老实说：这仍然是我经常重新投入工作的方式。不要告诉任何人。我应该是专家。

But then stuff actually started to happen. What usually happened was people complaining about what we’d delivered not working the way they wanted. Sometimes they didn’t complain at all (which we’d find out later was a side effect of no one really using it). We’d then spend a lot of time pretending we were successful. For some of you, that might describe the way your company works today. And I’ll be honest with you: it’s still the way I often fall back into working. Don’t tell anyone. I’m supposed to be an expert.

但是还有更好的选择。

But there are better alternatives.

多年前，一位潜在客户联系我，问我是否可以帮助它采用一种称为设计思维的过程。这个客户一直在使用典型的敏捷过程，并且做得非常好——“好”是因为它以可预测和高质量的方式交付。但它已经了解到，“你提供垃圾的速度越快，你得到的垃圾就越多。” 这听起来有点刺耳。换句话说，客户了解到，它构建的软件数量与它从中获得的结果和影响之间几乎没有关联。

Years ago, a potential client contacted me and asked me if I could help it adopt a process called design thinking. This client had been using a typical Agile process, and was doing it really well—“well” in that it was delivering predictably and with high quality. But it had learned that “the faster you deliver crap, the more crap you get.” That’s a little harsh sounding. To put it another way, the client had learned that there was little correlation between the quantity of software it built, and the outcome and impact it got from it.

当这个客户打电话时，我以我在用户体验设计和敏捷开发方面的专长而闻名。我心想：“我是设计师，我在思考，所以我一定是设计思维。” 但是我错了。客户不是这个意思。对我来说幸运的是，我没有大声说出我的想法。

When this client called, I was known for my specialty in user experience design and Agile development. I thought to myself: “I’m a designer, and I’m thinking, so I must be design thinking.” But I was wrong. That’s not what the client meant. Luckily for me, I didn’t say what I was thinking out loud.

设计思维是指一种工作方式，最初由一家名为 IDEO 的公司描述，后来由斯坦福大学的 d.school 描述和教授。如今，许多大学都在教授它，并在全球许多公司中使用它。

Design thinking refers to a way of working originally described by a company called IDEO, and then later described and taught by Stanford University’s d.school. These days, it’s taught in a number of universities and used in lots of companies worldwide.

设计思维过程有几个步骤，正如我解释的那样，这些步骤看起来显然是个好主意。但是，在实践中，我和大多数人倾向于做的恰恰相反。难怪事情经常变坏。

A design thinking process has several steps that, as I explain them, seem like obviously good ideas. But, in practice, what I and most people tend to do is the exact opposite. No wonder things go bad so often.

设计思维方法的第一步是同理心。这不叫研究，我通常希望在设计过程中进行研究。之所以称为同理心，是因为做这项工作的一个关键结果是了解成为您产品的用户的真实感受。为此，您需要前往用户所在的地方，与他们会面，观看他们的工作，最好是与他们一起工作。现在，当然，如果你为外科医生开发软件，没有人会期望你成为一名业余外科医生。但是尽你最大的努力去理解穿上他们的鞋子是什么感觉。重要的是要记住，在传统研究中，尤其是定量的不干涉的研究中，我们得到的是数据，而不是总是同理心。

The first step of a design thinking approach is empathize. It’s not called research, which I’d normally expect from a design process. It’s called empathize because a critical outcome of doing the work is to understand how it really feels to be a user of your product. To do this you need to go to where users are, meet them, watch them work, and ideally work alongside them. Now, of course, if you build software for surgeons, no one expects you to become an amateur surgeon. But do your best to understand what it’s like to walk in their shoes. It’s important to remember that out of traditional research, especially the quantitative hands-off stuff, we get data and not always empathy.

下一步称为定义。从我们在 empathize 期间所做的工作中，我们学到了很多东西。但我们需要理解它——建立共同的理解。为此，我们将通过大量协作来讲述故事、分享和提炼我们所学到的知识。然后我们将选择要关注的特定人员和问题。

The next step is called define. From the work we do during empathize, we learn a lot. But we need to make sense of it—to build shared understanding. And we’ll do this using lots of collaboration to tell stories, share, and distill what we’ve learned. Then we’ll choose specific people and problems on which to focus.

在此处使用故事地图来绘制当今人们做事的方式。在其中包括您所见所闻的详细信息。关注用户的痛点，以及他们寻求的回报。使用简单的角色来构建一个综合您所学知识的优秀示例用户。选择要关注的具体问题。

Use story maps here to map the way people do things today. Include in them details of what you saw and learned. Focus on the pain points users have, and the rewards they seek. Use simple personas to build a good example user that synthesizes what you’ve learned. Choose specific problems to focus on.

下一步是构思。如果你在上一章中有密切关注，我们谈到了一种叫做设计工作室的简单实践。这是一个好的构思方法的例子。在常见的商业实践中，第一个想出可行想法的人就是赢家，想出很多可能的想法似乎是在浪费时间。如果您还记得您的第一个显而易见的解决方案是非常明显的，那么如果想出一个创新的解决方案真的很重要，那就想想过去吧。

The next step is ideation. If you were paying close attention in the last chapter, we talked about a simple practice called design studio. It’s an example of a good ideation approach. In common business practice where the first person to come up with a viable idea is the winner, it seems a waste of time to come up with lots of possible ideas. If you remember that your first obvious solutions are, well, obvious, then if really coming up with an innovative solution is important, think past that.

我喜欢使用故事地图作为构思的背景。使用显示痛苦、快乐和其他用户信息的地图，然后直接将想法集思广益。将解决方案的想法直接写在卡片或便签纸上，并将它们注入解决方案最相关的地图中。

I like using a story map as a backdrop for ideation. Use a map that shows pains, joys, and other information about users, and then brainstorm ideas directly into it. Write solution ideas directly on cards or stickies and inject them into the map where the solution is most relevant.

下一步是制作原型。现在，我们可能都知道原型是什么，但我们常常在急于构建可运行的产品时忽略了创建原型。很遗憾，真的。对简单纸质原型的少量投资有助于我们思考解决方案。他们帮助我们开始亲身体验。用纸或最简单的原型制作工具构建简单的原型，可以帮助我们过滤掉很多行不通的想法。开始模拟使用产品的实际行为有助于您继续构思——想出让解决方案变得更好的想法。

The next step is to prototype. Now, we likely all know what prototypes are, but we often neglect creating them in the rush to get working products built. It’s a pity, really. Small investments in simple paper prototypes help us think through our solution. They help us begin to experience it ourselves. Building simple prototypes out of paper, or the simplest of prototyping tools, helps us filter out a lot of ideas that just won’t work. Beginning to simulate the actual act of using a product helps you continue to ideate—to come up with ideas to make the solution even better.

最后一步是测试。我并不是说检查是否有错误。我的意思是了解您的解决方案是否真的解决了某人的问题。您可能会感到惊讶，即使存在错误，它也能做到这一点。当你有一个你认为可以解决你选择关注的问题的原型时，把这个原型放在将使用你的产品的人面前。这不完全是“展示和讲述”。而且绝对卖不出去。潜在用户需要将原型视为他们可以用来解决他们的问题之一的东西。他们需要用它来完成真正的任务。你实际上可以通过伪造很多来实现这一点。

The last step is to test. By that I don’t mean check to see whether there are bugs. I mean learn whether your solution really does solve someone’s problem. You might be surprised that it could do that even with bugs. When you’ve got a prototype that you believe solves the problems you’ve chosen to focus on, put that prototype in front of people who’ll use your product. This isn’t exactly “show and tell.” And it’s definitely not selling. Potential users need to recognize the prototype as something they could use to solve one of their problems. They need to use it to accomplish a real task. You can actually accomplish this by faking a lot of it.

除了这五个步骤之外，设计思维的一部分是一种工作方式它强调小型、多学科的协作团队使用简单的模型、草图和低保真度的记录和交流方式快速合作。作为我在第 12 章中描述的发现团队和其他合作者，您应该认识到这一点。你应该认识到他们的工作方式是强调建立共同理解的方式。

In addition to those five steps, part of design thinking is a way of working that emphasizes small, multidisciplinary collaborative teams working together quickly using simple models, sketching, and low-fidelity ways of documenting and communicating. You should recognize that as the discovery team and other collaborators I described in Chapter 12. You should recognize their way of working as one that emphasizes building shared understanding.

使用设计思维的元素可以帮助我们真正理解我们正在解决的问题，所以我们不会解决我们想象的人们遇到的问题。在我们投入大量资金构建功能齐全的可扩展解决方案之前，对解决方案进行原型设计和测试有助于我们验证我们正在构建人们真正重视并可以使用的解决方案。

Using elements of design thinking helps us really understand the problems we’re solving, so we don’t solve problems we imagine people have. Prototyping and testing solutions before we invest big in building full-featured scalable solutions helps us validate that we’re building solutions people really value and can use.

但是单靠设计思维会导致一些问题。

But design thinking alone can lead to some problems.

设计过程已经存在了很长时间。设计思维作为一种通用的设计方法也有。一个好的设计过程可以比过去糟糕的日子有了巨大的进步。但是不要混淆过程和技巧。有一些可预测的设计流程失败方式。如果您看到一个好的设计过程花费太多时间并导致糟糕的结果，那么您可能会认为这些过程不起作用。这不是过程。

Design processes have been around a long time. Design thinking as a generalized approach to design has, too. And a design process done well can be a huge improvement over the bad old days. But don’t confuse process with skill. There are some predictable ways that design processes fail. If you’ve seen a good design process take way too much time and result in a bad outcome, then you might believe these sorts of processes don’t work. It’s not the process.

以下是一些扰乱设计过程的好方法：

Here are a few great ways to mess up a design process:

我知道我在这里有点刻薄。但我坚决主张使用设计流程。而且，奇怪的是，我发现我经常是抱怨他们的人。我还可以说，我对列出的几乎所有失败都感到内疚。但是，在过去的几年里，我发现了一种改进它们的典型设计方法的转折点。

I’m being a bit snarky here, I know. But I’m a strong advocate for using design processes. And, oddly, I find I’m often the one complaining about them. I can also say that I’ve been guilty of almost all the failures listed. But, over the past few years, I’ve found a twist on typical design approaches that improves them.

埃里克·里斯 (Eric Ries) 是一本名为《精益创业》（皇冠企业）的书的作者。埃里克在他的书中描述了他是如何陷入我之前描述为“糟糕的过去”的陷阱的。作为一家初创公司的首席技术官，他帮助他的公司打造了他们认为是成功的产品。只有他们的目标客户和用户不这么看。事实上，他们的回应大多是愉快的反馈、糟糕的反馈和彻底的冷漠。绝对不是他们想要的结果和影响。

Eric Ries is the author of a book called The Lean Startup (Crown Business). In his book Eric describes how he fell into the trap I described earlier as the “bad old days.” As the CTO of a startup, he helped his company build what they believed to be a successful product. Only their target customers and users didn’t see it that way. In fact, they mostly responded with a mixture of pleasant feedback, bad feedback, and outright apathy. Definitely not the outcome and impact they were looking for.

Eric 的公司顾问之一是 Steve Blank。史蒂夫写了一本书，叫做顿悟的四个步骤（K&S 牧场），他在书中断言，你需要开发的第一件事不是产品，而是客户。他描述了一个过程，用于逐步验证您是否找到了对解决方案感兴趣的客户，然后验证您想到的解决方案是他们将购买、使用并告诉其他人的解决方案。Blank 将此称为经过验证的学习过程。

One of Eric’s company advisors was Steve Blank. Steve had written a book called The Four Steps to Epiphany (K&S Ranch) in which he asserted that the first thing you need to develop isn’t a product, it’s customers. He described a process for progressively validating that you’ve found customers who are interested in a solution, and for then validating that the solutions you have in mind are the solutions they’ll buy, use, and tell others about. Blank referred to this as a validated learning process.

Eric Ries 对产品开发的最大贡献是将这种思维简化并“产品化”为这个简单的口头禅：构建-测量-学习。Eric 强调减少完成这个简单学习周期所需的时间。传统设计流程中最大的缺陷之一花很长时间学习和设计——时间太长以至于你对解决方案非常执着，然后却无法验证这些解决方案是否确实带来了你想要的结果。典型的设计过程可能需要数周或数月的时间来验证解决方案的想法，而精益启动过程通常只需要几天时间。

Eric Ries’s biggest contribution to product development is simplifying and “productizing” that thinking into this simple mantra: build-measure-learn. Eric emphasized reducing the time it takes to get through this simple learning cycle. One of the biggest flaws in traditional design processes is spending a very long time learning and designing—so long that you become very attached to the solutions, and then failing to validate that those solutions really do bring about the outcomes you intended. Where a typical design process may take weeks or months to validate a solution idea, a Lean Startup process usually takes just days.

在过去糟糕的日子里，我们会想出一个好主意，建造它，并希望最好的。

In the bad old days, we’d have come up with a big idea, built it, and hoped for the best.

如果我们试图通过严格的设计流程来打破这个陷阱，我们就会尽力搁置我们的伟大想法，然后深入研究以了解我们正在解决的问题。

If we were trying to break out of that trap using a rigorous design process, we’d have done our best to set aside our great ideas, and then dig deep into research to understand the problems we’re solving.

这是我建议我们今天做事的方式，使用精益创业思维。

Here’s how I recommend we do things today, using Lean Startup thinking.